Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 16 Mar 2005 16:44:14 -0500 (EST)
From:      "kalin mintchev" <kalin@el.net>
To:        "Charles Swiger" <cswiger@mac.com>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: kern.ipc.nmbclusters
Message-ID:  <54755.68.165.89.73.1111009454.squirrel@68.165.89.73>
In-Reply-To: <8ba66af9dfd749cff4ec033004d93fdc@mac.com>
References:  <52214.68.165.89.73.1110927742.squirrel@68.165.89.73> <1110945574l.25764l.2l@BARTON> <53058.68.165.89.73.1110948884.squirrel@68.165.89.73> <54481.68.165.89.73.1111003279.squirrel@68.165.89.73> <8ba66af9dfd749cff4ec033004d93fdc@mac.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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
>
>


--




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54755.68.165.89.73.1111009454.squirrel>