Hi, Michal... 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/ ------------------------------------------------------------------------- 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/