From owner-freebsd-questions@FreeBSD.ORG Wed Mar 16 20:19: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 46ED316A4CE for ; Wed, 16 Mar 2005 20:19:01 +0000 (GMT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1194A43D1F for ; Wed, 16 Mar 2005 20:19:01 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id j2GKIxsh009097; Wed, 16 Mar 2005 12:18:59 -0800 (PST) Received: from [10.1.1.245] (nfw2.codefab.com [199.103.21.225] (may be forged)) (authenticated bits=0)j2GKIvlV002204; Wed, 16 Mar 2005 12:18:58 -0800 (PST) In-Reply-To: <54481.68.165.89.73.1111003279.squirrel@68.165.89.73> 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> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8ba66af9dfd749cff4ec033004d93fdc@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Wed, 16 Mar 2005 15:18:56 -0500 To: kalin mintchev X-Mailer: Apple Mail (2.619.2) 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 20:19:01 -0000 On Mar 16, 2005, at 3:01 PM, kalin mintchev wrote: >> 11125 requests for memory denied >> 1 requests for memory delayed >> 0 calls to protocol drain routines You were exceeding the amount of socket buffer memory available there. >> 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. Perhaps the other side is playing games? If you do a tcpdump against that client, are you seeing responses with a 0 window size? -- -Chuck