Body
So, I'm still a hardcore GNU/Linux administrator after all ?!
Apache "The webserver" is down. Looks like the master process gets killed by the kernel. That's weird.
Now what's interesting is the dmesg output:
TCP: Treason uncloaked! Peer 62.68.70.130:62537/80 shrinks window 1681427947:1681430707. Repaired.
TCP: Treason uncloaked! Peer 62.68.79.66:61105/80 shrinks window 288684489:288684490. Repaired.
TCP: Treason uncloaked! Peer 62.68.79.66:61107/80 shrinks window 285018062:285018063. Repaired.
TCP: Treason uncloaked! Peer 62.68.79.66:61137/80 shrinks window 282542156:282542157. Repaired.
TCP: Treason uncloaked! Peer 62.68.79.66:61161/80 shrinks window 305746809:305746810. Repaired.
TCP: Treason uncloaked! Peer 62.68.79.66:61185/80 shrinks window 341351133:341351134. Repaired.
TCP: Treason uncloaked! Peer 62.68.79.66:61213/80 shrinks window 356410419:356410420. Repaired.Looks like the peer is playing bad games with my TCP/IP stack. Decreasing the window size. I guess that's why apache was holding too many connections. Something like 119 connections.
netstat output was interesting:
88 CLOSE_WAIT
21 SYN_RECVI wouldn't know but I guessed that the high number of SYN requests is due gto the high number of half closed sockets.
The problem is that after I've decreased the CLOSE_WAIT time via:
echo 2 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_waitThe number of TIME_WAIT started to increase.
echo 10 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait Of course all the above might be incorrect or even nonsense. Let's see.
- 23410 views
Add new comment