I'd rather not increase number of SQL connection - this does not solve the problem - just makes it less noticeable. Under high load new calls should be rejected, but this is not so simple - we have to wait a bit before a new call is rejected (some timeout). If there exists some timeout - you will always find some CPS value, that will block the system. The only solution would be to set a hard limit for TCP connections/calls and reject new call attempts as soon as possible. But then you will loose CDRs.. ----- Original Message ----- From: "Edson" <4lists@xxxxxxxxx> Sent: Thursday, August 03, 2006 4:12 PM > I think that You hit the point... the combination of remote DB and available > connections. In my config, I had "MinPoolSize=5". But, as You pointed out, a > slow accounting can consume all available SQL connections. As a test, I grow > up MinPoolSize, from 5 to 15 and started a job to count the GK threads each > 5 seconds... The number is stable around 18~19 threads... > > I'll let the whole system under observation and will return results to the > list. > > One more question: if this problem (growing number of busy threads, 'til > system exhausting) is derived from a low number on free SQL connections, > wouldn't the new calls have to be rejected, before stucking the system? > > Edson. > >> -----Original Message----- >> From: openh323gk-users-bounces@xxxxxxxxxxxxxxxxxxxxx [mailto:openh323gk- >> users-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Zygmuntowicz Michal >> Sent: quinta-feira, 3 de agosto de 2006 08:00 >> To: GNU Gatekeeper Users >> Subject: Re: Controlling Threads >> >> If you have 4CPS and an accounting update works as slow as 250ms >> and you have MinPoolSize=1 or your backend cannot process queries >> in parallel because for some table locks, you will hang your machine with >> 100% load. >> Even 100-150 secs for accounting with serialized database access can >> cause problems with 4CPS. And having a backend on a machine that is longer >> than a few millisecs from the gk is very bad idea. >> >> ----- Original Message ----- >> From: "Edson" <4lists@xxxxxxxxx> >> Sent: Thursday, August 03, 2006 3:40 AM >> >> >> Hi, Bruno... >> >> Just in case, I start the debug/trace to narrow the problem down. With or >> without trace of any level the problem occurs. It didn't start to occur >> after I start the tracing vigilance. >> >> It is cyclical... I just have to have some established calls (say 20-30, >> maybe 40) and a load of something bigger then 3/4 cps and it start slow >> the >> machine down 'til it consumes all CPU and, in this moment, I see the >> number >> of threads growing like 2/3 threads each 'top' cycle (2 seconds). I had >> see >> 93 threads before the SSH access stucked. >> >> >> >> Edson. >> >> >> >> _____ >> >> From: openh323gk-users-bounces@xxxxxxxxxxxxxxxxxxxxx >> [mailto:openh323gk-users-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Bruno >> Lopes de Souza Benchimol >> Sent: quarta-feira, 2 de agosto de 2006 20:55 >> To: 'GNU Gatekeeper Users' >> Subject: Re: Controlling Threads >> >> >> >> What happens when you stop debugging? You know that debug consumes a lot >> of >> "power" in any device, also consider checking you ram/swap usage, I hope >> that's low enough. >> >> >> >> >> >> >> >> _____ >> >> From: openh323gk-users-bounces@xxxxxxxxxxxxxxxxxxxxx >> [mailto:openh323gk-users-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Edson >> Sent: Wednesday, August 02, 2006 3:01 PM >> To: 'GNU Gatekeeper Users' >> Subject: Re: Controlling Threads >> >> >> >> Ok, there was the motivation for my question on how to obtain the state of >> each running thread... With more RAM, I see that after a while the thread >> number drop to the normal (something like 8~10 threads) and the CPU >> consumption falls back from 99.9% (not to say 100%... ;) ) to 1~2% (as >> expected). >> >> >> >> Reviewing the debug messages generated by the system I find, p.ex.: >> >> ... >> >> 2006/08/02 14:38:37.054 2 RasTbl.cxx(2029) >> CallTable::Insert(CALL) Call No. 939, total sessions : 7 >> >> ... >> >> 2006/08/02 14:38:37.422 3 gkacct.cxx(944) GKACCT SQLAcct >> logged event 1 for call no. 939 >> >> 2006/08/02 14:38:37.422 2 gkacct.cxx(984) GKACCT >> Successfully >> logged event 1 for call no. 939 >> >> ... >> >> 2006/08/02 14:38:56.993 3 gkacct.cxx(944) GKACCT SQLAcct >> logged event 2 for call no. 939 >> >> 2006/08/02 14:38:56.993 3 gkacct.cxx(944) GKACCT FileAcct >> logged event 2 for call no. 939 >> >> 2006/08/02 14:38:56.993 2 gkacct.cxx(984) GKACCT >> Successfully >> logged event 2 for call no. 939 >> >> ... >> >> 2006/08/02 14:39:01.209 3 RasTbl.cxx(1368) Gk Delete >> Call >> No. 939 >> >> ... >> >> >> >> As the SQLAcct is been maded on another machine (217 ms away), I suppose >> that this time gaps are ok. >> >> >> >> I would appreciate help in debugging this behavior, but I need some >> guidance... Please let me know how to collect the ecessary informations... >> >> >> >> Edson. >> >> >> >> P.S.: just to let You know: this GK is not configured as a proxy machine. >> It's only a H.323 'router', acting as a Gatekeeper-Directory. >> >> >> >> > -----Original Message----- >> >> > From: openh323gk-users-bounces@xxxxxxxxxxxxxxxxxxxxx [mailto:openh323gk- >> >> > users-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Zygmuntowicz Michal >> >> > Sent: quarta-feira, 2 de agosto de 2006 11:42 >> >> > To: GNU Gatekeeper Users >> >> > Subject: Re: Controlling Threads >> >> > >> >> > An interesting observation - the number of threads should not go so high >> >> > with such low volumes. Maybe there is some problem with thread pool >> >> > management - I am not sure. Are all/most of these threads busy? >> >> > I would suspect an auth/acct module being a bottleneck, but as you noted >> >> > this is not the case. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________________ Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users Homepage: http://www.gnugk.org/
