|
Hello Venci,
Thanks for the reply and suggestion.
Your suggestion was exactly what I was
thinking as a solution but after awhile I came to this conclusion that
this could not be a good solution. Stacking a bunch of computers is
not a suitable work around in a real world.
Even if we stack tens of computers and
set them to handle only 80 to 100 calls each, still there is no guarantee
that it would work safe without harming anyone.
Believe me if you add up the cost of the
computers that you have to bring in, the time that have to spend to prepare all
of them and manage the network with complete uncertainty and also the stress
that you would go through because of the unreliable nature of the software
that you are using, your would reach to a number way higher than what you have
to spend for a reliable solution which is commercially available in
the market.
From what I saw and after all the time that
I've spent on GNUGK, I can say it is a very nice piece of work but unfortunately
it is good only for beginners to make experiments out of it. Maybe a start
up business with some limited traffic also could take advantage of its
features. But It
is certainly not as reliable as it should be comparing to the current
reliable available commercial solutions (which interestingly some of them had
used GNUGK as their start up platform).
Once again thank you for the suggestion. At
least it showed the problem was based on GNUGK's nature not
my lack of knowledge. Still I will play with GNUGK here and there but I don't
think I would look at it as a serious replacement for
anything.
Thanks to everyone who is putting time and
effort to make GNUGK as good as it should be, is helping others with their
problems and is sharing their knowledge and experiments.
Bahram
----- Original Message -----
Sent: Sunday, January 22, 2006 5:57
AM
Subject: Re: Could we
call this a CRASH?
Hello Bahram ,
here is what i can suggest . You can
use severa PC with GnuGK runing on it in full proxy mode and you can put one
or more PC with GnuGK for round-robbin balancing on the backend machines. And
this way you can manage to get less then 100 concurent calls per GnuGK . I am
telling you this solution cuz that way i saw with my eyes how 600 concurent
calls are connected with about 40-50calls/sec . Sure it won`t solve your
problem but i think this is more correct way to do this and sure you make the
platform more redundant . The people who runs that platform was having issues
with single GnuGK crash on about 100-150 concurent calls in full proxy mode .
I hope this will help you .
BR,
Venci.
On 1/18/06, Bahram S.
Biria <bsbiria@xxxxxxxxxxxxx> wrote:
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/
|
