From owner-freebsd-stable@FreeBSD.ORG Thu Mar 30 18:45:19 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0DEE16A401 for ; Thu, 30 Mar 2006 18:45:19 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: from smtpout10-04.prod.mesa1.secureserver.net (smtpout10-04.prod.mesa1.secureserver.net [64.202.165.238]) by mx1.FreeBSD.org (Postfix) with SMTP id 2AED143D53 for ; Thu, 30 Mar 2006 18:45:18 +0000 (GMT) (envelope-from Stephen.Clark@seclark.us) Received: (qmail 10852 invoked from network); 30 Mar 2006 18:45:18 -0000 Received: from unknown (24.144.77.138) by smtpout10-04.prod.mesa1.secureserver.net (64.202.165.238) with ESMTP; 30 Mar 2006 18:45:18 -0000 Message-ID: <442C273D.105@seclark.us> Date: Thu, 30 Mar 2006 13:45:17 -0500 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22smp i686; en-US; m18) Gecko/20010110 Netscape6/6.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stable@freebsd.org References: <442B23CA.3060808@seclark.us> <20060330034353.GR60807@ufanet.ru> <442B56B2.1070107@seclark.us> <20060330053231.GS60807@ufanet.ru> In-Reply-To: <20060330053231.GS60807@ufanet.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: 4.9 network not freeing memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephen.Clark@seclark.us List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2006 18:45:19 -0000 damir bikmuhametov wrote: >On Wed, Mar 29, 2006 at 10:55:30PM -0500, Stephen Clark wrote: > > >>>Try to increase net.inet.ip.intr_queue_maxlen and monitor >>>net.inet.ip.intr_queue_drops. >>> >>> >>Increasing net.inet.ip.intr_queue_maxlen to 400 seems to have fixed the >>problem. >> >> > >Could you please report this to the list after some testing? > >Thanks. > > > Do you know if the queue_maxlen is exceeded do the mbufs get lost? It sort of seems that is what happens. This is after a test where I was increment queue_maxlen til queue_drops were not increasing. $ sysctl net.inet.ip.intr_queue_drops net.inet.ip.intr_queue_drops: 27444 X10001:~ At this point the network after my test the network is pretty much quiet. But there are still mbufs allocated for data?? $ netstat -m 689/5504/131072 mbufs in use (current/peak/max): 689 mbufs allocated to data 265/4958/32768 mbuf clusters in use (current/peak/max) 11292 Kbytes allocated to network (11% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines After a reboot: X10001:~ $ sysctl net.inet.ip.intr_queue_drops net.inet.ip.intr_queue_drops: 0 X10001:~ $ netstat -m 2/416/131072 mbufs in use (current/peak/max): 2 mbufs allocated to data 0/44/32768 mbuf clusters in use (current/peak/max) 192 Kbytes allocated to network (0% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines This after a reboot and another test with queue_maxlen=400 Note there are only 3 mbufs allocated to data. sysctl net.inet.ip.intr_queue_drops net.inet.ip.intr_queue_drops: 0 X10001:~ $ netstat -m 3/416/131072 mbufs in use (current/peak/max): 3 mbufs allocated to data 0/44/32768 mbuf clusters in use (current/peak/max) 192 Kbytes allocated to network (0% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines Is there some way to see what the current queue length is? Like the queue drops. What do you think? Regards, Steve