kern.ipc.nmbclusters

[kalin mintchev]

thanks Charles...

>
> You were exceeding the amount of socket buffer memory available there.

i'm aware of that. the question is why?

>>> huge difference. so i think about 260 lines of netstat -p tcp output
>>> like:
>>>
>>> tcp4       0  33580  server.http              c68.112.166.214..3307
>>> FIN_WAIT_1
>>>
>>> has to do with all these 6000 clusters. but i'm not sure how. DOS may
>>> be?!
>>> they are all from the same client ip and all of them have much higher
>>> number for send then received Q's. what does the state FIN_WAIT_1
>>> mean?
>>> waiting to finish? if so - why it didn't do that for hours and hours.
>>> my
>>> web server keeps connections alive for 10 sec. there isn't much else
>>> that
>>> uses tcp on that machine. the webserver was inaccessile for about 5-10
>>> min. so my first thought was DOS... "11125 requests for memory denied"
>>> made it look like it was a DOS...
>>>
>>> maybe somebody can explain the relation if any. it'll be
>>> appreciated...
>
> FIN_WAIT_1 means that one side of the TCP conversation sent a FIN, and
> the other side (yours) wants to flush the queue of unsent data and will
> then close the connection.  It's not clear why this isn't working, and
> there is a timer which gets started which ought to close the connection
> after 10 minutes or so if no data can be sent.

well that was what i was suggesting in my post but the sever is set to cut
inactive connections after 10 seconds - not minutes. is there any other
timer i'm missing here?

>
> Perhaps the other side is playing games?  If you do a tcpdump against
> that client, are you seeing responses with a 0 window size?

that happened yesterday - 1/2 hr ago. right now it is fine... quite....
i tought DOS. it hasn't happened before. right now using only 250-300
clusters which is the normal...

thanks...


>
> --
> -Chuck
>
>


--