|
Thanks Michal,
I am not sure which part of the result
of the "sysctl -a" command is really important to be examined in terms of the
limitations which might cause problems for GNUGK to work
flawless.
Would you mind to have a quick look at the
result of the command (attached) for me and let me know about the
parts which might look not proper to your eyes? I really appreciate
all your help.
Regards,
Bahram.
P.S. I am yet to receive the comments
from the people who are using GNUGK in real world with no
problem handling a middle class volume of traffic (about 200
concurrent calls in full proxy mode)
----- Original Message -----
Sent: Wednesday, January 18, 2006 11:29
AM
Subject: Re: Could we
call this a CRASH?
Maybe you need to examine various kernel variables - try sysctl
-a
to check OS limits.
----- Original Message -----
From:
"Bahram S. Biria" <bsbiria@xxxxxxxxxxxxx>
Sent:
Tuesday, January 17, 2006 9:09 PM
A brief hardware and software
specification is as follows:
Server:
Intel Double Xeon with 1G
memory and SCSI harddrives - The following is the first section of "top"
(while the GNUGK was running but
with no
action):
15:37:58 up 2 days, 13:02, 2 users,
load average: 0.00, 0.00, 0.00
48 processes: 47 sleeping, 1 running, 0
zombie, 0 stopped
CPU0 states: 0.0% user 0.0%
system 0.0% nice 0.0% iowait 100.0% idle
CPU1
states: 0.0% user 0.1% system 0.0%
nice 0.0% iowait 99.4% idle
CPU2 states: 0.0%
user 0.0% system 0.0% nice 0.0%
iowait 100.0% idle
CPU3 states: 0.0% user 0.0%
system 0.0% nice 0.0% iowait 100.0%
idle
Mem: 1030184k av, 1011544k used, 18640k
free, 0k shrd, 75964k
buff
688628k actv, 14296k in_d, 133660k in_c
Swap: 2040244k
av, 5784k used, 2034460k
free
279704k cached
GNUGK:
version 2.2.3-2 compiled with large fdset
equal to 32768 and in "optnoshared" mode
Version:
Gatekeeper(GNU)
Version(2.2.3) Ext(pthreads=1,radius=1,mysql=1,pgsql=0,large_fdset=32768)
Build(Jan 4 2006, 17:16:31) Sys(Linux
i686
2.4.20-31.9smp)
GkStatus: Version(2.0) Ext()
Toolkit: Version(1.0)
Ext(basic)
OS:
Linux RedHat 9.0 - the ulimit also is increased to
32768
[root@MTGK02 unix]# uname -a
Linux MTGK02 2.4.20-31.9smp #1
SMP Tue Apr 13 17:40:10 EDT 2004 i686 i686 i386 GNU/Linux
[root@MTGK02
unix]#
[root@MTGK02 unix]# ulimit -n
32768
The available
resources in a glance looks way more than enough for handling the GNUGK with
about 150 concurrent calls in full proxy
mode.
What could possibily
be the reason of hiting the resource limits on a machine which its only active
process is GNUGK? Since there is
no other process (other than system
processes) to use any kind of resources, of course except mysql, first thing
coming to mind is
that GNUGK is using some resources and is not releasing
them properly.
I am not sure if I missed something in OS installation
or GNUGK compilation/configuration; OR it is a part of GNUGK's nature when it
is used under somehow heavy real load.
It is really interesting to
know if there is anyone who is using GNUGK in an environment with about 500
concurrent calls in full
proxy mode and more than 20 call requests in a
second at peak; and has no problem at all with it (let say the GNUGK is
working for
them for about a month in this environment without even being
touched)? Even hearing from someone who is using GNUGK under the real
traffic with 100 to 200 concurrent calls in full proxy mode for weeks and
with no issues is really appreciated. In that case at
least I could be
sure that whatever the problem is, it is coming from only me and it is not a
general issue.
Michal, thank you for the suggestions and showing the
problem is lack of resources but do you have any idea why this large amount of
capcity and resource is being used by GNUGK in about an hour with
something like 100 to 150 concurrent calls?
Thanks to everybody who
shares their thoughts on this,
Bahram.
----- Original Message
-----
From: Zygmuntowicz Michal
To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Sent: Tuesday, January 17, 2006 8:03 AM
Subject: Re:
Could we call this a CRASH?
This second
message confirms that GnuGk process hits its limit
of opened file
handles. If you check line 724 of tlibthrd.cxx,
you will probably
find a call to a system function socketpair
- and this call asserts
in case of socket allocation failure.
----- Original Message
-----
From: "Bahram S. Biria" <bsbiria@xxxxxxxxxxxxx>
To: <openh323gk-users@xxxxxxxxxxxxxxxxxxxxx>
Sent: Monday, January 16, 2006 11:44 PM
Subject: Re:
Could we call this a CRASH?
I also could
see the following error message as well which might be
interesting.
2006/01/15 06:20:57.339
0
assert.cxx(108) PWLib Assertion fail: Operating System
error, file tlibthrd.cxx, line
746,
Error=24
Maybe
this error message shed a light on what the problem
is.
-------------------------------------------------------
This
SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for
problems? Stop! Download the new AJAX search engine that
makes
searching your log files as easy as surfing the web.
DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________________
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/
|
