I'd recommend observing GnuGK memory usage growth. There have been some reports about excessive memory consumption. As a temporary solution I can recommend periodic service restart during idle hours.
----- Original Message ----- From: "Alex Golyshev" <[EMAIL PROTECTED]> Sent: Sunday, February 18, 2007 4:56 PM > Yes, you are right. TOP said that CPU usage is about 100% > > last pid: 9257; load averages: 1.02, 1.00, 0.78 up 53+13:00:58 15:02:01 > 50 processes: 2 running, 48 sleeping > CPU states: 73.3% user, 0.0% nice, 26.7% system, 0.0% interrupt, 0.0% idle > Mem: 55M Active, 693M Inact, 180M Wired, 44M Cache, 110M Buf, 16M Free > Swap: 2005M Total, 84K Used, 2005M Free > > Memory is also seems to be exhasted. Is it some memory leak in gnugk? > > Other stats: > > %netstat -s -p tcp > tcp: > 13644382 packets sent > 8182965 data packets (1054165771 bytes) > 28826 data packets (9213821 bytes) retransmitted > 7753 data packets unnecessarily retransmitted > 0 resends initiated by MTU discovery > 3994884 ack-only packets (1874075 delayed) > 0 URG only packets > 0 window probe packets > 25261 window update packets > 1412446 control packets > 16225442 packets received > 9619140 acks (for 1051061672 bytes) > 714837 duplicate acks > 0 acks for unsent data > 6876534 packets (706198705 bytes) received in-sequence > 12175 completely duplicate packets (655564 bytes) > 145 old duplicate packets > 1051 packets with some dup. data (69771 bytes duped) > 36363 out-of-order packets (11418118 bytes) > 0 packets (0 bytes) of data after window > 0 window probes > 25536 window update packets > 20958 packets received after close > 6 discarded for bad checksums > 0 discarded for bad header offset fields > 0 discarded because packet too short > 484742 connection requests > 451499 connection accepts > 15180 bad connection attempts > 0 listen queue overflows > 62 ignored RSTs in the windows > 910231 connections established (including accepts) > 955108 connections closed (including 7854 drops) > 471100 connections updated cached RTT on close > 471438 connections updated cached RTT variance on close > 205811 connections updated cached ssthresh on close > 663 embryonic connections dropped > 9586399 segments updated rtt (of 9156114 attempts) > 56844 retransmit timeouts > 253 connections dropped by rexmit timeout > 0 persist timeouts > 0 connections dropped by persist timeout > 502 keepalive timeouts > 472 keepalive probes sent > 30 connections dropped by keepalive > 18391 correct ACK header predictions > 4994989 correct data packet header predictions > 452456 syncache entries added > 2483 retransmitted > 2229 dupsyn > 0 dropped > 451499 completed > 0 bucket overflow > 0 cache overflow > 449 reset > 193 stale > 0 aborted > 0 badack > 315 unreach > 0 zone failures > 0 cookies sent > 0 cookies received > 1871 SACK recovery episodes > 2313 segment rexmits in SACK recovery episodes > 2935473 byte rexmits in SACK recovery episodes > 16182 SACK options (SACK blocks) received > 4508 SACK options (SACK blocks) sent > 0 SACK scoreboard overflow > > %netstat -m -p tcp > 7/758/765 mbufs in use (current/cache/total) > 0/134/134/25600 mbuf clusters in use (current/cache/total/max) > 0/128 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max) > 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) > 1K/457K/459K bytes allocated to network (current/cache/total) > 776457/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/8/6656 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 5040 calls to protocol drain routines > > I'll try to use recent CVS 2.2.6 version. Maybe it will work fine? > > Regards, > Alex. > > Zygmuntowicz Michal пишет: > >>Did you try to examine CPU/memory usage with top or other utility? >>One strange thing I notice is that in you log, the timeout happens >>immediatelly >>after connecting the socket. >> >>----- Original Message ----- >>From: "Alex Golyshev" <[EMAIL PROTECTED]> >>Sent: Saturday, February 17, 2007 7:14 PM >> >> >> >> >>>Hi all. >>> >>>I've found a strange bug (?) in gnugk 2.2.5. After some working time gk >>>starts to drop calls with reason 102 (Recovery from timer expiry). >>>Log tells me that gk can't establish Q931 TCP connection wih remote >>>party: >>> >>>2007/02/17 18:45:12.290 3 ProxyChannel.cxx(2946) Q931 Connect >>>to xx.xx.xx.xx:1720 from yy.yy.yy.yy:0 successful >>>2007/02/17 18:45:12.290 3 yasocket.cxx(654) Q931d >>>xx.xx.xx.xx:1720 Error(1): Input/output error (12:57) >>>2007/02/17 18:45:12.290 3 ProxyChannel.cxx(2618) Q931 Timed >>>out waiting for a response to Setup message from xx.xx.xx.xx:1720 >>> >>>So looks like gk gets some bad info from destinaion.. But from that >>>moment many calls to different ip-addresses drop with the same error. >>>I calculated that there was 15% of successful calls to usual value. >>>After restarting gk returns to the normal state: calls are going through >>>with no problem. >>> >>>I'm not sure that it is a gnugk problem, maybe calls drop due to tcp/ip >>>full socket buffers etc. >>> >>>Gnugk 2.2.5, release version with the prefix prioroty patch. Failover is >>>enabled, full proxy mode. >>>OpenH323 1.18.0, PWLib 1.10.0. FreeBSD 6.1-Release. >>> >>>Does anybody have similar problems? >>> >>>Regards, >>>Alex. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________________ Posting: mailto:[email protected] Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users Homepage: http://www.gnugk.org/
