Re: MaxConnect
Poster reported that bursts of more than ~30 simultaneous new connections could hang IDS 9.40.UC7/7.31.UD on a 10-CPU Solaris box, despite 7 CPU VPs and NETTYPE tlitcp allowing ~1400 connections, and asked whether MaxConnect was needed. Replies suggested the OS TCP stack may be badly tuned (watch for rising q-exceed/sar stats), though no specific parameters or values were given. Another reply explained the real bottleneck is usually the single listener thread per protocol, which can be overwhelmed by connection bursts (worsened by slow DNS), causing some connect requests to fail — but a full server hang would be a bug to report to Tech Support. No confirmed fix is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
" posed a similar question several months ago and the concensus was with that number of users Maxconnect is unnecessary. Regards Colin " Well I am seeing problems when we get >30 simultanous new connections. It can hang IDS 9.40.UC7/ 7.31.UD(7/8) on Solaris even on a 10 cpu machine with 7 cpu vps and 7 poll threads NETTYPE running tlitcp on CPU VPs. The nettype allows 7*200=1400 connections. Has anyone seen this before?
> " posed a similar question several months ago and the concensus was > with > that number of users Maxconnect is unnecessary. > > Regards > > > Colin " > > Well I am seeing problems when we get >30 simultanous new connections. > It can hang > IDS 9.40.UC7/ 7.31.UD(7/8) on Solaris even on a 10 cpu machine with 7 > cpu vps and > 7 poll threads NETTYPE running tlitcp on CPU VPs. The nettype allows > 7*200=1400 connections. > > Has anyone seen this before? Sounds like a poorly configure TCP stack, have you tweaked the tcp settings ? Paul Watson Tel: +44 1414161772 Mob: +44 7818003457 GO FURTHER with DB2 GET THERE FASTER with Informix. Attend the IDUG 2006 North America Conference. Tampa, Florida, USA. 7-11 May 2006. Visit http://www.iiug.org/conf for more information.
"Sounds like a poorly configure TCP stack, have you tweaked the tcp settings ? " Which setttings? To what values? How do I tweak them?
Shouldn't network poll threads run in NET VP's?
Hi, the bottleneck here is not poll threads. The bottleneck is most probably the listener thread. Usually you have only one listener thread for each protocol in use. (Situations where you have more than one mostly are when you are listening to connect requests on separate network cards.) The listener thread is listening for new connections, accepting them, doing some basic checks and then handing the connection over to an sqlexec thread for doing the actual work. If there are too many connect requests at once, the (poor) listener thread can get "overwhelmed". So some of the simultaneous connect requests can go unanswered, resulting in some error on the client side. This can be exacerbated by slow DNS responses or similar things (as there are DNS calls involved in connection establishment). However, such a situation should not cause IDS to get hung in a sense that everything stops working. Already connected users should still be able to get their work done and stay unaffected by the burst of connect requests. If such a situation causes the IDS server to hang completely, and only a restart of IDS can alleviate the problem, then this sounds like a bug (to be reported via Tech Support ...). TIA, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management informix-list-bounces@iiug.org wrote on 11.02.2006 21:27:18: > " posed a similar question several months ago and the concensus was > with > that number of users Maxconnect is unnecessary. > > Regards > > > Colin " > > Well I am seeing problems when we get >30 simultanous new connections. > It can hang > IDS 9.40.UC7/ 7.31.UD(7/8) on Solaris even on a 10 cpu machine with 7 > cpu vps and > 7 poll threads NETTYPE running tlitcp on CPU VPs. The nettype allows > 7*200=1400 connections. > > Has anyone seen this before? > > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list
> Hi, > > the bottleneck here is not poll threads. The bottleneck is most > probably the listener thread. Usually you have only one listener > thread for each protocol in use. (Situations where you have more > than one mostly are when you are listening to connect requests > on separate network cards.) > > The listener thread is listening for new connections, accepting them, > doing some basic checks and then handing the connection over to > an sqlexec thread for doing the actual work. If there are too many > connect requests at once, the (poor) listener thread can get > "overwhelmed". So some of the simultaneous connect requests can > go unanswered, resulting in some error on the client side. This can > be exacerbated by slow DNS responses or similar things (as there > are DNS calls involved in connection establishment). > > However, such a situation should not cause IDS to get hung in a sense > that everything stops working. Already connected users should still be > able to get their work done and stay unaffected by the burst > of connect > requests. If such a situation causes the IDS server to hang > completely, > and only a restart of IDS can alleviate the problem, then > this sounds like > a bug (to be reported via Tech Support ...). [cutting] If the tcp stack is not configured to handle a high concurrency of fast spawning connections you tend to see q-exceed rising rapidly. It can rise under other conditions as well but in my experience rapid changes are due to tcp configur errors. You can see tcp problems under sar as well. Paul Watson Tel: +44 1414161772 Mob: +44 7818003457 GO FURTHER with DB2 GET THERE FASTER with Informix. Attend the IDUG 2006 North America Conference. Tampa, Florida, USA. 7-11 May 2006. Visit http://www.iiug.org/conf for more information.