From owner-freebsd-stable Thu Jul 23 20:14:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA26833 for freebsd-stable-outgoing; Thu, 23 Jul 1998 20:14:03 -0700 (PDT) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from orion.aye.net (orion.aye.net [206.185.8.9]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id UAA26777 for ; Thu, 23 Jul 1998 20:13:56 -0700 (PDT) (envelope-from rabtter@orion.aye.net) Received: (qmail 23079 invoked by uid 3759); 24 Jul 1998 03:14:47 -0000 Date: Thu, 23 Jul 1998 23:14:46 -0400 (EDT) From: "B. Richardson" To: Markus Stumpf cc: freebsd-stable@FreeBSD.ORG Subject: Re: swap/memory management problem In-Reply-To: <19980724035956.H11327@space.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This would actually be a good posting for squid-users@ircache.net. I had the same sort of hurdles. My cache was quite a bit smaller (12 gig) and a 166 Mhz with 256 meg of ram. When it went into swap, it was like an instant logjam (our peak connection rate was around 45,000 connections per hour). When squid memory usage got around 190 mb we had a little pageing activity with a noticable degradation in performance. At 175 mb there was no paging, response was good, but we started noticing thing like DNS times in the cachemgr getting higher (like .4 seconds) and spikes in the number of page scans per second in the output of vmstat. We kept backing off the cache_mem setting until all this went away, and now swap usage is 0. Squid peaks at around 170 mb (our cache is smaller that yours and the nature of our userload may be different accounting for slight differences in memory usage patterns). Around 1/3 of physical memory is a fairly common starting point for the cache_mem is a good starting point and you can tweak it from there. If you reduce swap to 30 mb, I'm convinced you will get the dreaded "could not allocate 4096 bytes" error. Swap is the enemy. Your 300 Mhz may be a bit more immune to the performance degredation but any swapping at all on our 166 Mhz really killed us under heavy load. - Barrett Richardson rabtter@orion.aye.net On Fri, 24 Jul 1998, Markus Stumpf wrote: > System: FreeBSD 2.2.5-RELEASE #0 > CPU: Pentium Pro (300.68-MHz 686-class CPU) > real memory = 268435456 (262144K bytes) > avail memory = 256962560 (250940K bytes) > Swap space configured 300 MB. > > The machine is dedicated as cache/proxy server using squid-1.22-NOVM. > No other tasks than the minimum system processes running. > We have about 1.8 million objects in cache. > Squid claims memory demand of 178768 KB. > > Now the problem: > > If I start squid fresh it starts to read its "database" and grows in memory. > As soon as it reaches about 170 MB the systems starts to swap. Swap space > is filling slowly but after one day approx about 240 MBs are used. > > The follwing numbers are from squid running for about 50 hours now. > > "top" reports: > -------------- > Mem: 129M Active, 47M Inact, 42M Wired, 32M Cache, 8224K Buf, 784K Free > Swap: 300M Total, 238M Used, 62M Free, 79% Inuse, 12K In > > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND > 8021 root 2 -15 235M 173M select 135:57 0.38% 0.38% squid > > "systat -vmstat": > ----------------- > Mem:KB REAL VIRTUAL > Tot Share Tot Share Free > Act 196604 548 247308 704 36252 count > All 255936 676 1195900 1432 pages > > 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? > > Thanks > > \Maex > > P.S. If there are any more infos on the system I could provide which would > help to solve the problem, I'd be glad to do so. > > -- > SpaceNet GmbH | http://www.Space.Net/ | If you don't think women > Research & Development | mailto:research@Space.Net | are explosive, drop one! > Frankfurter Ring 193a | Tel: +49 (89) 32356-0 | > D-80807 Muenchen | Fax: +49 (89) 32356-299 | > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message