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/
