Connections blocked - Connect Timeout Expired

Hello all, I am trying to investigate a transient issue where new connections appear to get blocked and result in a Connect Timeout Expired. It has happened when the database is busy with server side tasks and it has also happened when just the application is busy. However in neither case has the engine been unusually busy (ie. existing sessions still get fairly responsive transactions and the hardware load isn't concerning). As such this looks to correlate with how busy the engine is and engine resources. We use connection pooling. Which engine resources could be running out to result in new connections being blocked? How can I monitor which resources are getting 'low' or have run out etc? which onconfig tokens should I be interested in? A select that normally takes a fraction of a second was only taking 2 or 3 seconds, but the new connection tried for 15 seconds and gets a 'Connect Timeout Expired'. Log from our software; 26/06/2010 14:09:38.776 - 4006 - Fatal exception while performing test: System.ArgumentException: Connect Timeout Expired. 26/06/2010 14:09:38.776 - 4006 - at IBM.Data.Informix.IfxConnectionPool.ReportOpenTimeOut() 26/06/2010 14:09:38.776 - 4006 - at IBM.Data.Informix.IfxConnectionPool.Open(IfxConnection connection) 26/06/2010 14:09:38.776 - 4006 - at IBM.Data.Informix.IfxConnPoolManager.Open(IfxConnection connection) 26/06/2010 14:09:38.776 - 4006 - at IBM.Data.Informix.IfxConnection.Open() 26/06/2010 14:09:38.776 - 4006 - at Monitor.Common.Database.DatabaseBase.GetNewConnection() 26/06/2010 14:09:38.776 - 4006 - at Monitor.Common.Database.DatabaseBase.get_Connection() 26/06/2010 14:09:38.776 - 4006 - at Monitor.Common.Database.DatabaseConnectionReturningASingleObject`1.Execute() 26/06/2010 14:09:38.776 - 4006 - at Monitor.Fep.Process.SystemMonitor.ClassDetails.DBCheck.ExecuteCommand(String storedProc, String database, String[] paramList, Int32 timeOut, Test test) 26/06/2010 14:09:38.776 - 4006 - at Monitor.Fep.Process.SystemMonitor.ClassDetails.DBCheckTest.GetResult() 26/06/2010 14:09:38.776 - 4006 - at Monitor.Fep.Process.SystemMonitor.ClassDetails.Test.Run() 26/06/2010 14:09:38.776 - 4006 - FAIL (1) - returned from Test "Sentinel WD Client Running Status" - Fatal exception while performing test: Connect Timeout Expired. (14999ms) Thank you in advance for your time. Regards, Andy.

Of you are using shares memory connections they are limited by the NETTYPE setting in the ONCONFIG file. Art On Jul 6, 2010 8:15 AM, "ANDREW LEMIN" <a_lemin@hotmail.com> wrote: Hello all, I am trying to investigate a transient issue where new connections appear to get blocked and result in a Connect Timeout Expired. It has happened when the database is busy with server side tasks and it has also happened when just the application is busy. However in neither case has the engine been unusually busy (ie. existing sessions still get fairly responsive transactions and the hardware load isn't concerning). As such this looks to correlate with how busy the engine is and engine resources. We use connection pooling. Which engine resources could be running out to result in new connections being blocked? How can I monitor which resources are getting 'low' or have run out etc? which onconfig tokens should I be interested in? A select that normally takes a fraction of a second was only taking 2 or 3 seconds, but the new connection tried for 15 seconds and gets a 'Connect Timeout Expired'. Log from our software; 26/06/2010 14:09:38.776 - 4006 - Fatal exception while performing test: System.ArgumentException: Connect Timeout Expired. 26/06/2010 14:09:38.776 - 4006 - at IBM.Data.Informix.IfxConnectionPool.ReportOpenTimeOut() 26/06/2010 14:09:38.776 - 4006 - at IBM.Data.Informix.IfxConnectionPool.Open(IfxConnection connection) 26/06/2010 14:09:38.776 - 4006 - at IBM.Data.Informix.IfxConnPoolManager.Open(IfxConnection connection) 26/06/2010 14:09:38.776 - 4006 - at IBM.Data.Informix.IfxConnection.Open() 26/06/2010 14:09:38.776 - 4006 - at Monitor.Common.Database.DatabaseBase.GetNewConnection() 26/06/2010 14:09:38.776 - 4006 - at Monitor.Common.Database.DatabaseBase.get_Connection() 26/06/2010 14:09:38.776 - 4006 - at Monitor.Common.Database.DatabaseConnectionReturningASingleObject`1.Execute() 26/06/2010 14:09:38.776 - 4006 - at Monitor.Fep.Process.SystemMonitor.ClassDetails.DBCheck.ExecuteCommand(String storedProc, String database, String[] paramList, Int32 timeOut, Test test) 26/06/2010 14:09:38.776 - 4006 - at Monitor.Fep.Process.SystemMonitor.ClassDetails.DBCheckTest.GetResult() 26/06/2010 14:09:38.776 - 4006 - at Monitor.Fep.Process.SystemMonitor.ClassDetails.Test.Run() 26/06/2010 14:09:38.776 - 4006 - FAIL (1) - returned from Test "Sentinel WD Client Running Status" - Fatal exception while performing test: Connect Timeout Expired. (14999ms) Thank you in advance for your time. Regards, Andy. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum. --00163645835ea939c7048ab76e10

Hi Art, As always thank you for your very prompt and helpful responses. Currently NETTYPE is 'NETTYPE soctcp,7,350,CPU'. Are there any scaling recommendations for this token? 'netstat -an' shows 125 sockets to the turbo port on the database (currently everything is working fine) at the moment. I do not have a 'netstat -an' figure at the time the problem occurs because the issue only seems to last for around one minute. Thanks again. Andy.

Only a guess: Did you check the message log on check point duration or long transactions? Reinhard. > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of ANDREW > LEMIN > Sent: Tuesday, July 06, 2010 5:39 PM > To: ids@iiug.org > Subject: Re: Connections blocked - Connect Timeout Expired [20523] > > Hi Art, > > As always thank you for your very prompt and helpful responses. > > Currently NETTYPE is 'NETTYPE soctcp,7,350,CPU'. > > Are there any scaling recommendations for this token? > > 'netstat -an' shows 125 sockets to the turbo port on the database (currently > everything is working fine) at the moment. I do not have a 'netstat -an' > figure at the time the problem occurs because the issue only seems to last for > around one minute. > > Thanks again. > Andy. > > > ************************************************************************ ******* > Forum Note: Use "Reply" to post a response in the discussion forum.

Yes, but are the clients that are being blocked coming in to a TCP/IP SERVERNAME/DBSERVERALIAS or into one that's defined (in the sqlhosts file) as an ipcshm connection type? If that, and you do not have an explicit NETTYPE setting for ipcshm (shared memory connections), the default setting is for a single poll thread configured for 50 concurrent connections only. It will be running on NET VPs if the connection name is listed in DBSERVERALIASES or in a CPU VP if the name is listed as the SERVERNAME. Note that unlike TCP connections, the number of concurrent connections that the engine can handle is fixed at startup by the NETTYPE setting for ipcshm and cannot handle more than the configured number. TCP connection types, however, can expand the number of slots they listen for dynamically and so should never have a resource problem. That's why I keep asking about your shared memory connections. BTW, you should NOT be running TCP/IP poll threads in the CPU VPs. Since the CPU VPs cannot be blocked on the socket, they have to poll the port periodically. The busier the CPU VPs get, the less often they will have free cycles to poll the ports so that there will be responsiveness and timeout problems. Inversely, as the number of new connections and new requests from existing connections goes up there will be fewer free cycles in the CPU VP to handle the additional load and queries will seem to take longer. The rule of thumb that's been developed over years is to configure TCP/IP connections in NET VPS only and to have one for every 200-350 concurrent connections you expect to have to handle. Shared memory connections should always and only be configured to use CPU VP poll threads since you can't block on a shared memory read anyway, this prevents the NET VPs from having to spin on the memory reads and permits them to block on the TCP socket(s) thereby reducing the CPU usage and freeing cycles to get work done. Also, if shared memory connections are used ONLY for maintenance with only occasional connections, there should be two poll threads for each, but if the shared memory connections will be used by client applications then there should be an ipcshm poll thread in every CPU VP. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Tue, Jul 6, 2010 at 11:39 AM, ANDREW LEMIN <a_lemin@hotmail.com> wrote: > Hi Art, > > As always thank you for your very prompt and helpful responses. > > Currently NETTYPE is 'NETTYPE soctcp,7,350,CPU'. > > Are there any scaling recommendations for this token? > > 'netstat -an' shows 125 sockets to the turbo port on the database > (currently > everything is working fine) at the moment. I do not have a 'netstat -an' > figure at the time the problem occurs because the issue only seems to last > for > around one minute. > > Thanks again. > Andy. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001636417c0352e298048aba6d8a

Hi Art, Thank you. That response was really useful. We have had a chat in the office and we have decided based on your comments to try the following change; Change 'NETTYPE soctcp,7,350,CPU' to 'NETTYPE soctcp,5,500,NET' Based on your suggestion I guess we should actually be setting 2 poll threads and not 5, however other in the office here to not want to make to big a change. I will let you know how we get on.

Hi, Yes we checked the usual places including check point critical time (>0.0001), overall checkpoint time(>0.001), Cached IO (<97%), lock counts (~180) etc. As such everything is fairly normal at the time the new connections are blocked, albeit a slightly higher load. We are going to try changing 'NETTYPE soctcp,7,350,CPU' to 'NETTYPE soctcp,5,500,NET'.

If you really do have 2500 concurrent connections you should be using the 7 poll threads with 350 connections each. IBM recommends using not more than 300-350 connections per poll thread. So, take that as the guide. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Thu, Jul 8, 2010 at 11:37 AM, ANDREW LEMIN <a_lemin@hotmail.com> wrote: > Hi Art, > > Thank you. That response was really useful. We have had a chat in the > office > and we have decided based on your comments to try the following change; > > Change 'NETTYPE soctcp,7,350,CPU' to 'NETTYPE soctcp,5,500,NET' > > Based on your suggestion I guess we should actually be setting 2 poll > threads > and not 5, however other in the office here to not want to make to big a > change. > > I will let you know how we get on. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --000e0cd70f4a7b840a048ae35062

Hello, Sorry for the slow response. We have made the changes on site now finally. We changed; 'NETTYPE soctcp,7,350,CPU' to 'NETTYPE soctcp,7,350,NET' And; 'VPCLASS cpu,num=7,noage' to 'VPCLASS net,num=7,noage' We should now be running 7 dedicated network poll threads (each one capable of handling up to 350 connections) instead of hijacking the CPU threads. I plan on bringing the figure 7 down to around 3 to 5 as we do not really run that many concurrent connections, but can only make one change at a time etc. During the change we noticed the following online log entry; 13:57:57 Onconfig parameter NUMCPUVPS modified from 7 to 1. The server has 8 CPU cores. We want 1 reserved for the OS, and we want the other 7 cores to be available to the IDS engine. Using 'htop' I can see that only CPU 1 is running above 1% etc. Cores 2 - 8 seem idle. Should we now also add the token 'NUMCPUVPS' to the onconfig (doesn't exist at the moment) as 'NUMCPUVPS 7', to ensure the engine continues to use 7 CPU threads/7 cores etc? I also noticed that VPCLASS doesn't seem to be used anymore now that the NETTYPE token is set to NET, and so changing it was pointless. Does this matter? I have also noticed that the token 'NUMAIOVPS' also seems to have been applied by default (currently not in onconfig). I assume this will create 2 IO threads, and the 'AUTO_AIOVPS 1' token should allow this number of IO threads to grow as needed? TOKENS; cf_name cf_flags cf_original cf_effective SINGLE_CPU_VP 0 0 0 NUMCPUVPS 0 NULL 1 NUMAIOVPS 0 NULL 2 NETTYPE 0 soctcp,7,350,CPU soctcp,7,350,NET VPCLASS 0 net,num=7,noage VP_MEMORY_CACHE_KB 0 0 0AUTO_AIOVPS 0 1 1 As always, thank you kindly for all your time and help. Cheers, Andy.

NUMCPUVPS was deprecated in 9.40 and will soon be desupported altogether so don't worry about that one. However, the message about changing NUMCPUVPS from 7 to 1 is worrysome. The VPCLASS cpu should have overridden the default for NUMCPUVPS (ie 1) and set the number of CPU VPs to 7. What does onstat -g glo report as the number of CPU VPs that are running? As to keeping the 7-8 cores busy, unless you put the 'aff' affinity option into the VPCLASS parameter setting, the OS is responsible for assigning the running oninit processes to the CPUs, so there should not be a problem there. I think that VPCLASS is ignored for NET VPs as they are controlled by the NETTYPE setting. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Fri, Jul 16, 2010 at 6:52 AM, ANDREW LEMIN <a_lemin@hotmail.com> wrote: > Hello, Sorry for the slow response. We have made the changes on site now > finally. > > We changed; > 'NETTYPE soctcp,7,350,CPU' to 'NETTYPE soctcp,7,350,NET' > And; > 'VPCLASS cpu,num=7,noage' to 'VPCLASS net,num=7,noage' > > We should now be running 7 dedicated network poll threads (each one capable > of > handling up to 350 connections) instead of hijacking the CPU threads. I > plan > on bringing the figure 7 down to around 3 to 5 as we do not really run that > many concurrent connections, but can only make one change at a time etc. > > During the change we noticed the following online log entry; > 13:57:57 Onconfig parameter NUMCPUVPS modified from 7 to 1. > > The server has 8 CPU cores. We want 1 reserved for the OS, and we want the > other 7 cores to be available to the IDS engine. Using 'htop' I can see > that > only CPU 1 is running above 1% etc. Cores 2 - 8 seem idle. > > Should we now also add the token 'NUMCPUVPS' to the onconfig (doesn't exist > at > the moment) as 'NUMCPUVPS 7', to ensure the engine continues to use 7 CPU > threads/7 cores etc? > > I also noticed that VPCLASS doesn't seem to be used anymore now that the > NETTYPE token is set to NET, and so changing it was pointless. Does this > matter? > > I have also noticed that the token 'NUMAIOVPS' also seems to have been > applied > by default (currently not in onconfig). I assume this will create 2 IO > threads, and the 'AUTO_AIOVPS 1' token should allow this number of IO > threads > to grow as needed? > > TOKENS; > cf_name cf_flags cf_original cf_effective > SINGLE_CPU_VP 0 0 0 > NUMCPUVPS 0 NULL 1 > NUMAIOVPS 0 NULL 2 > NETTYPE 0 soctcp,7,350,CPU soctcp,7,350,NET > VPCLASS 0 net,num=7,noage > VP_MEMORY_CACHE_KB 0 0 0> AUTO_AIOVPS 0 1 1 > > As always, thank you kindly for all your time and help. > Cheers, Andy. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --000e0cd754927cd509048b7f8ff4

Hi Art, The 'CPCLASS' token seems to be completly ignored now that we have chanegd the NETTYPE. sysmaster:sysconfig shows that VPCLASS was 'net,num=7,noage' and is now '' (Ie. NULL/nothing etc even though it is still defined in the onconfig!) onstat -g glo;CLASS VPS CPU 1 AIO 2 LIO 1 PIO 1 ADM 1 SOC 7 MSC 1 NET 7 This confirms that only 1 CPU VP is running, and 7 NET VP are running. Just checked again and the string 'VPCLASS net,num=7,noage' does exist in the onconfig. Should this instead be 'VPCLASS cpu,num=7,noage' with the new NETTYPE set to NET? And do you think we should set 'NUMCPUVPS 7' in the mean time even if it is soon depreciated? informix@db2:~> informix@db2:~> onstat -g glo IBM Informix Dynamic Server Version 11.50.FC2 -- On-Line (Prim) -- Up 03:31:18 -- 2871644 Kbytes MT global info: sessions threads vps lngspins 145 182 21 7 sched calls thread switches yield 0 yield n yield forever total: 45986756 29602714 17444474 200249 2126342 per sec: 8 8 0 0 4 Virtual processor summary: class vps usercpu syscpu total cpu 1 2961.85 247.87 3209.72 aio 2 0.04 0.14 0.18 lio 1 0.00 0.02 0.02 pio 1 0.00 0.02 0.02 adm 1 0.07 0.20 0.27 soc 7 54.47 118.81 173.28 msc 1 0.67 0.87 1.54 net 7 0.20 0.29 0.49 total 21 3017.30 368.22 3385.52 . . . Andy.

This is what I think you should do: 1. Open a case with IBM about this it isn't correct behavior. 2. Yes, set NUMCPUVPS to 7 for now. 3. As soon as possible upgrade from 11.50FC2 to 11.50.FC6 or higher (get IBM to give you the latest patch release). The xC2 release (actually all releases before xC4) is seriously broken - Dynamic SQL in SPL doesn't work correctly, SPL procedures randomly return extra non-existent values that cause errors in the calling routine, incorrect results can be returned from certain queries, more. Much of this is fixed by xC6. 4. Don't change the NETTYPE settings, you have them set correctly. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Fri, Jul 16, 2010 at 9:49 AM, ANDREW LEMIN <a_lemin@hotmail.com> wrote: > Hi Art, > > The 'CPCLASS' token seems to be completly ignored now that we have chanegd > the > NETTYPE. > sysmaster:sysconfig shows that VPCLASS was 'net,num=7,noage' and is now '' > (Ie. NULL/nothing etc even though it is still defined in the onconfig!) > > onstat -g glo;> CLASS VPS > CPU 1 > AIO 2 > LIO 1 > PIO 1 > ADM 1 > SOC 7 > MSC 1 > NET 7 > > This confirms that only 1 CPU VP is running, and 7 NET VP are running. > > Just checked again and the string 'VPCLASS net,num=7,noage' does exist in > the > onconfig. Should this instead be 'VPCLASS cpu,num=7,noage' with the new > NETTYPE set to NET?> > And do you think we should set 'NUMCPUVPS 7' in the mean time even if it is > soon depreciated? > > informix@db2:~> > informix@db2:~> onstat -g glo > > IBM Informix Dynamic Server Version 11.50.FC2 -- On-Line (Prim) -- Up > 03:31:18 > -- 2871644 Kbytes> > MT global info: > sessions threads vps lngspins > 145 182 21 7 > > sched calls thread switches yield 0 yield n yield forever > total: 45986756 29602714 17444474 200249 2126342 > per sec: 8 8 0 0 4 > > Virtual processor summary: > class vps usercpu syscpu total > cpu 1 2961.85 247.87 3209.72 > aio 2 0.04 0.14 0.18 > lio 1 0.00 0.02 0.02 > pio 1 0.00 0.02 0.02 > adm 1 0.07 0.20 0.27 > soc 7 54.47 118.81 173.28 > msc 1 0.67 0.87 1.54 > net 7 0.20 0.29 0.49 > total 21 3017.30 368.22 3385.52 > > .. > .. > .. > > Andy. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001517479356488597048b81cca9

Bugger, looks like we shouldn't have changed the VPCLASS token. We changed it on recommendation from our DBA when changing NETTYPE to NET. Currently; NETTYPE soctcp,7,350,NET VPCLASS net,num=7,noage I will change this to; NETTYPE soctcp,7,350,NET VPCLASS cpu,num=7,noage If we still have only 1 CPU VP after I set VPCLASS to cpu,num=7,noage (note the 'cpu'), I will set NUMCPUVPS to 7 and open a case with bell micro. I will discuss engine upgrades with our DBA. Thank you for your time and help Art. Regards, Andy. PS; Stuart Stephens (my manager who you met at one of the Informix conferences a while back) sends his thanks for your help too.

OH, I misunderstood your post. YES, changing the VPCLASS from cpu,... to net,... and so not having either NUMCPUVPS or VPCLASS cpu,... definitely is the reason why you only have one CPU VP running. And since you only have one CPU VP, the NET ipcshm,7,350,CPU is actually running six of its poll threads in the NET VPs (since there aren't seven CPU VPs available) which is hurting performance by sapping CPU cycles. Still think that you should upgrade ASAP, but hold off on opening a case until we see if this change fixes the CPU VP problem. Say "Hi." to Stuart for me, and you are both welcome. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Fri, Jul 16, 2010 at 10:33 AM, ANDREW LEMIN <a_lemin@hotmail.com> wrote: > Bugger, looks like we shouldn't have changed the VPCLASS token. > We changed it on recommendation from our DBA when changing NETTYPE to NET. > > Currently; > NETTYPE soctcp,7,350,NET > VPCLASS net,num=7,noage> > I will change this to; > NETTYPE soctcp,7,350,NET > VPCLASS cpu,num=7,noage> > If we still have only 1 CPU VP after I set VPCLASS to cpu,num=7,noage (note > the 'cpu'), I will set NUMCPUVPS to 7 and open a case with bell micro. > > I will discuss engine upgrades with our DBA. > > Thank you for your time and help Art. > > Regards, Andy. > > PS; Stuart Stephens (my manager who you met at one of the Informix > conferences > a while back) sends his thanks for your help too. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --000e0cd6e4b2924712048b824059

LOOKS LIKE WE HAVE A BUG!!! With; NETTYPE soctcp,7,350,NET VPCLASS net,num=7,noage Results in; 7 Network VP, and 1 CPU VP. With; NETTYPE soctcp,7,350,NET VPCLASS cpu,num=7,noage We are back to where we started; Results in; 1 Network VP and 7 CPU VP! 'onstat -g glo' was used to confirm this. We want 7 Network VP AND 7 CPU VP? I have not tried setting the NUMCPUVPS token. Thanks for your time. Andy.

Correction (zero NET VPS after changing VPCLASS to cpu); With; NETTYPE soctcp,7,350,NET VPCLASS net,num=7,noage Results in; 7 Network VP, and 1 CPU VP. With; NETTYPE soctcp,7,350,NET VPCLASS cpu,num=7,noage Results in; 0 Network VP and 7 CPU VP!

I didn't follow this thread, but I think you're missing one point: VPCLASS can be specified more than once, for different CPU VP classes. Please use: NETTYPE soctcp,7,350,NET VPCLASS net,num=7,noage VPCLASS cpu,num=7,noage assuming you want 7 CPU VPs, 7 NET CPU VPs and 7 poll threads. Regards. On Mon, Jul 19, 2010 at 4:40 PM, ANDREW LEMIN <a_lemin@hotmail.com> wrote: > Correction (zero NET VPS after changing VPCLASS to cpu); > > With; > NETTYPE soctcp,7,350,NET > VPCLASS net,num=7,noage> > Results in; 7 Network VP, and 1 CPU VP. > > With; > NETTYPE soctcp,7,350,NET > VPCLASS cpu,num=7,noage> > Results in; 0 Network VP and 7 CPU VP! > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --0015175cd7f25bc586048bc110a7