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>