From: Ciccio on
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
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