From owner-freebsd-hackers Sun Jul 26 22:02:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA09997 for freebsd-hackers-outgoing; Sun, 26 Jul 1998 22:02:06 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA09887 for ; Sun, 26 Jul 1998 22:01:59 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id AAA00372; Mon, 27 Jul 1998 00:01:07 -0500 (EST) (envelope-from toor) Message-Id: <199807270501.AAA00372@dyson.iquest.net> Subject: Re: swap/memory management problem In-Reply-To: <19980726154226.A2270@panke.de> from Wolfram Schneider at "Jul 26, 98 03:42:26 pm" To: w@panke.de.freebsd.org (Wolfram Schneider) Date: Mon, 27 Jul 1998 00:01:07 -0500 (EST) Cc: maex-freebsd-hackers@Space.Net, freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wolfram Schneider said: > On 1998-07-24 03:59:56 +0200, Markus Stumpf wrote: > > Watched this a loooong ;-) time and never seen pages swapped out but only in. > > > > The nasty thing with this is that squid is getting slower and slower and > > even so the above numbers do no change its getting slower every day it > > runs until I restart it. > > > > I assume this all is due to proactive swapping? > > > > Is there any chance to get rid of this behaviour? Would it help to reduce > > the swap space to e.g. 30 MB? (the 27 GB disk is filled, so I don't think > > squid will grow any further). Anything else I'm missing? > > There are several (undocumented) syctl variables which > control swapping and paging. You can also disable swapping at all. > > $ sysctl -a | grep ^vm > > vm.loadavg: { 0.91 0.94 1.00 } > vm.v_free_min: 161 > vm.v_free_target: 607 > vm.v_free_reserved: 124 > vm.v_inactive_target: 1398 > vm.v_cache_min: 810 > vm.v_cache_max: 3242 > vm.v_pageout_free_min: 34 > vm.pageout_algorithm: 0 > vm.swapping_enabled: 1 > Firstly, how big is squid? Is it bigger than physical memory? How much bigger than physical memory is it? You are probably not swapping but paging. If you are right on the edge is space, try halving vm.v_inactive_target and vm.v_free_target. Do not modify v_free_min, or even more critically, vm.v_free_reserved, unless you increase them slightly. Try also increasing/decreasing vm.v_cache_min -- that is a relatively insensitive control, but does change the disk caching behavior. If your system seems to "seize" due to paging (not "syncing"), you might try doubling the following: vm.v_pageout_free_min, vm.v_free_reserved and vm.v_free_min Also, decreasing vm.v_inactive_target to 75% of it's value might decrease paging (but will decrease the quality of the stats towards an LRU algorithm.) The pageout algorithm can be changed grossly by changing vm.pageout_algorithm=1, which converts the statstical paging algorithm to a more simplistic LRU approximation (this is useful if your locality of reference is flat and doesn't have a usable statistical skew.) -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message