|
Frank,
I could say you are one of the active
members of this forum helping others as much as you can, so I understand your
defensive guard against what I wrote. I wasn't blaming anybody or anything.
I just represented my honest opinion on the way that GNUGK worked for
me. I am sure you are getting something better than what I expected to
get.
I personally appreciate all your and
other active members of this forum's efforts in being helpful which would
definitely save a lot of time to others and educate them better and
quicker regarding pros and corns of using GNUGK. Keep up with the good working.
BTW, find my thoughts about your
lines below.
Cheers,
Bahram.
----- Original Message -----
Sent: Tuesday, January 24, 2006 2:31
AM
Subject: RE: Could we
call this a CRASH?
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.
<bahram> This is just
a matter of different opinions. It might not be true to you but it is to
me.
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.
<bahram> We are not trying to play with the
words, are we? If it is not a media proxy then the proxy feature should not
be included in. While it is there, working properly and reliably could be
expected if we try to think of GNUGK as a professional artwork. As something
to play with, no complaints.
- And: you need to know how gnugk works and
how to deploy it.
<bahram>
That was exactly what I was trying to do but unfortuantely couldn't
reach to anywhere as there were only two sources for this, the manual and
this forum which none helped me much on the specific case that I've
had.
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.
<bahram> It was not completely free
for me since I put value to my time. Regarding being opensource, If
you mean since it is opensource it could not be expected to be reliable; I
do have a different opinion. The operating system that most of
us compiled and used the GNUGK on; Linux; is also an opensource. I see
a strong reliability in it with thousands of installations in critical
mission networks. At least more reliable than Microsoft windows which
everybody has to pay for. So in my opinion being opensource is
not equal to expecting unreliability, again if we talk professionally.
For an educational project that has been done by someone to get his/her
degree and only wants to share it with others, you are absolutely
right. But we are at this point because I believe
GNUGK is not even comparable to an educational project which simply is
being shared with others. It is a fabulous artwork prepared by
smart people in the benefit of everyone.
I hope the developers of the GNUGK don't get me
wrong. They have done a tremendous job putting all these together and
bringing it to the place where it is. What is sad
to me is that after all these glorious accomplishments and hard
works they are so close to have something completely
reliable but I think the quality is made sacrificed for
having quantity (no offence to anyone, it is just my
opinion). Sure soon everybody could see all these problems are
gone.
- 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/
|
