Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Jul 1998 23:14:46 -0400 (EDT)
From:      "B. Richardson" <rabtter@aye.net>
To:        Markus Stumpf <maex-freebsd-hackers@Space.Net>
Cc:        freebsd-stable@FreeBSD.ORG
Subject:   Re: swap/memory management problem
Message-ID:  <Pine.SGI.3.95.980723225338.8930B-100000@orion.aye.net>
In-Reply-To: <19980724035956.H11327@space.net>

next in thread | previous in thread | raw e-mail | index | archive | help

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SGI.3.95.980723225338.8930B-100000>