|
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 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 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: > 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.
Esta mensagem foi verificada pelo E-mail Protegido Terra. Scan engine: McAfee VirusScan / Atualizado em 01/08/2006 / Versão: 4.4.00/4819 Proteja o seu e-mail Terra: http://mail.terra.com.br/ |
------------------------------------------------------------------------- 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/
