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,
[<fi>
] That's simply not true.
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).
[<fi> ] Again, that's not true. Maybe you should
consider two facts:
- what is GNGK to be used for`? - > it's
a gatekeeper, no softswitch, no media proxy, just a gatekeeper. If
you try to do other things with it, you are on your own. But you
shouldn't blame GNUGK then if you run into
problems.
- And: you need to know how gnugk works and
how to deploy it.
And after all: gnugk is opensource and you can
use it for free. So if you find a bug in it, you're absolutely free to
fix it.
- Frank
----- 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/
|
