From owner-freebsd-questions@FreeBSD.ORG Wed Mar 16 21:44:01 2005 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26D7B16A4CE for ; Wed, 16 Mar 2005 21:44:01 +0000 (GMT) Received: from mail.el.net (mail.el.net [68.165.89.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8AFCF43D1D for ; Wed, 16 Mar 2005 21:44:00 +0000 (GMT) (envelope-from kalin@el.net) Received: (qmail 22728 invoked by uid 1008); 16 Mar 2005 21:44:14 -0000 Received: from unknown (HELO mail.el.net) (127.0.0.1) by mail.el.net with SMTP; 16 Mar 2005 21:44:14 -0000 Received: from 68.165.89.73 (SquirrelMail authenticated user kalin@el.net); by mail.el.net with HTTP; Wed, 16 Mar 2005 16:44:14 -0500 (EST) 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> Date: Wed, 16 Mar 2005 16:44:14 -0500 (EST) From: "kalin mintchev" To: "Charles Swiger" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal cc: freebsd-questions@freebsd.org Subject: Re: kern.ipc.nmbclusters X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2005 21:44:01 -0000 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 > > --