Prev: Problems while trying to set up a Kerberos 5 server on user ports
Next: Queries: How to split SVM mirror and apply patch
From: Ciccio on 28 Jan 2010 04:34 On Jan 26, 9:01 pm, nelson <nelson.bens...(a)gmail.com> wrote: > > Not really, I think that the value is in milliseconds. According to > > Stevens, MAX_WAIT_TIME is 2MSP, where MSP is typically 30, 60 or 120s. > > This is a the bottom of that range. I suppose that as networks have > > gotten faster (or latencies shorter), then having lower MSP is safer. > > i meant the number of connections in time_wait, not the time. takes > time for pkts to clear the wire... Ok, Thank you for your replies. It got to a point where I had to reboot the box, but chances are it will happen again (as it has done so far), it usually happens within 10 to 15 days after each reboot. To clear things up, no ZFS in use, no zones. The box is reasonably patched, kernel patch is 141445-09 . The prstat output didn't show anything unusual. As per now, load averages: 0.26, 0.26, 0.25; up 5+22:43:34 09:30:27 45 processes: 44 sleeping, 1 on cpu CPU states: 85.6% idle, 13.4% user, 1.0% kernel, 0.0% iowait, 0.0% swap Memory: 3840M phys mem, 3268M free mem, 4103M total swap, 4103M free swap [krypton]$ netstat -an | grep -c TIME.WAIT 5 [krypton]$ Ciccio
From: Darren Dunham on 22 Feb 2010 19:06
On Feb 22, 2:28 am, Ciccio <lser...(a)gmail.com> wrote: > OK, it's happening again, now. > Anything TCP running on the box (namely, ssh, httpd and Big Brother) > have sockets in TIME_WAIT state. > > [krypton]/tmp$ netstat -an | grep -c TIME_WAIT[krypton]/tmp$ netstat - > an | grep TIME_WAIT > 10.159.244.250.22 10.159.244.22.49046 5840 0 49232 0 > TIME_WAIT > 10.159.244.250.43492 10.159.244.249.1984 6912 0 49640 0 > TIME_WAIT Did the clock on your box change (especially backward)? I remember seeing similar things during Y2K testing. If you look at a specific line, does it remain in the output after 4 minutes? -- Darren |