I'd recommend observing GnuGK memory usage growth. Therehave been some reports about excessive memory consumption.As a temporary solution I can recommend periodic service restartduring idle hours. ----- Original Message ----- From: "Alex Golyshev" <alex.golyshev@xxxxxxx>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" <alex.golyshev@xxxxxxx>>>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 ITJoin SourceForge.net's Techsay panel and you'll get the chance to share youropinions on IT & business topics through brief surveys-and earn cashhttp://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________________ Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxxxxxxxxx: http://sourceforge.net/mailarchive/forum.php?forum_id=8549Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-usersHomepage: http://www.gnugk.org/
