Jan, thanks for a prompt reply! I am aware of OS limits for file descriptors that imply on top of precompiled values, but its not the case - they are big enough and also set explicitly before gnugk launch with ulimit command, exactly as you said :) And to the slow release of ports by operating system - I can understand that, but taking into account dynamics of port allocation and release it comes to the point where all 4096 file handles are busy, and 99% of them are UDP sockets. I'll illustrate dynamic with two snapshots, taken with 2.5 hours in between; also, first one was taken shortly after gnugk restart: # netstat -alnp | grep -c gnugk.67 270 # grep Num gnugk-status-67-prev.log Number of Calls: 26 Active: 21 From Neighbor: 26 From Parent: 0 And 2nd one, just few minutes ago: # netstat -alnp | grep -c gnugk.67 1674 # grep Num gnugk-status-67-prev.log Number of Calls: 31 Active: 24 From Neighbor: 31 From Parent: 0 File gnugk-status-67-prev.log is updated every 20 seconds from status port. Maybe I should go for bigger verbosity in logs? Current level is 3, does not show any errors or warnings right now. Best regards, Vladyslav. On 13/06/07, Jan Willamowius <jan@xxxxxxxxxxxxxx> wrote: > Hi Vladyslav, > > recomopiling GnuGk with a larger fdset isn't enough. You also have to > raise the operating system limits for file descriptors (usually 'ulimit > -n <num>'). > > The linear growth you describe would be a resource leakage that > shouldn't happen. Sometimes it takes quite a while for the OS to free a > closed socket, but when you call volume goes down your file descriptor > usage should go down, too. If it doesn't we'll have to debug GnuGk if > there are cases where sockets aren't properly closed. > > Regards, > Jan > > > Vladyslav Bakayev wrote: > > Hello all, > > > > during last few days my setup of gnugk got into some trouble. At some > > point gnugk gets full of opened udp ports with reasonable number of > > current calls, and could not open any more because of the limits > > enforced at compile time (large_fdset=4096). At this point log is full > > of lines: > > > > 2007/06/11 18:41:28.449 1 ProxyChannel.cxx(3802) RTP RTCP > > socket xx.xx.xx.67:55821 not available - error 7/24: Cannot allocate > > memory > > > > To confirm the shortage of sockets, I've did "lsof -n -p <gnugk pid>" > > and counted lines with "wc -l", which was exactly 4096. > > > > Restart of gnugk resolved the trouble, but it does take like 20-30 > > hours till it gets full of udp open ports again. Taking a look at the > > number of open ports shows more or less linear growth. Recompiling > > with bigger large_fdset value will only postpone the moment of gnugk > > getting stuck. > > > > Can I have any hints what should be checked and how? I could build > > "debug" version of pwlib 1.10.7, openh323 1.18.0 and gnugk, if that > > comes handy. -- SY, Vlad. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________________ Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users Homepage: http://www.gnugk.org/
