RE: [SQU] CPU use stuck at 100%

Jeremy,

I have a similar/same problem. The GETTIMEOFDAY() you see there might in
fact have something to do with your REPLACEMENT_POLICY. LRU, the default
REPLACEMENT_POLICY compile option is known to be broken in STABLE3
(http://www.squid-cache.org/Versions/v2/2.3/bugs/#squid-2.3.stable3-storeExp
iredReferenceAge). When Squid needs drive space it gets rid of data that's
original timestamp is over the REFERENCE_AGE (my assumption please correct
me if I'm wrong here :). By default Squid sets this to 1 YEAR. If that is
the case squid never deletes old objects and your drive space continues to
fill up, even if it is over the CACHE_DIR's size limit. Even changing the
CACHE_SWAP_LOW, CACHE_SWAP_HIGH settings didn't solve the associated
problem. I finally solved it by making REFERENCE_AGE=1 WEEK. Now my squid
process eats tremendous CPU time - not to mention tremendous memory, but
that's another problem - which I attribute to the large cache volume
combined with the large load associated with removing cache files.

So far all I can deduce is that this is normal Squid operating procedure if
you are running STABLE3 with these problems.

Comments would be appreciated. Thanks.

-Chris Allan <callan@gt.ca>

-----Original Message-----
From: Jeremy M. Dolan [mailto:jmd@foozle.turbogeek.org]
Sent: Thursday, November 09, 2000 1:58 PM
To: squid-users@ircache.net
Subject: Re: [SQU] CPU use stuck at 100%

Well, I recieved a reply (off list) briefly mentioning something about
syncio. It also mentioned I should have provided info on the OS the
machine is running, which it seems I forgot.

# uname -a
Linux sol 2.2.13 #127 Thu Oct 21 13:13:20 CDT 1999 i586 unknown
(its actually a Slackware Linux 7.0 install).

Squid version is 2.3.STABLE3, but I looked through the changes for
STABLE4 and didn't see anything that seemed to address my symptoms. As
I mentioned before this machine is in production use so I'd hate to
risk an upgrade if it wouldn't even fix the problem.

I looked through the docs provided, the FAQ, and Henrik's Sourceforge
pages, and only found one refereance to squid using 100% CPU, in which
case the fix was to make sure you had a /dev/null, which I do.

Here's an strace, this time with the time being shown:

# strace -tt -p 18598
15:38:20.591947 gettimeofday({973805900, 594019}, NULL) = 0
15:38:20.595060 poll(0xbfffdc64, 0x2, 0, 0x40167520, 0xbfffdc64) = 0
15:38:20.596871 gettimeofday({973805900, 597448}, NULL) = 0
15:38:20.598019 poll(0xbfffdc64, 0x2, 0, 0x40167520, 0xbfffdc64) = 0
15:38:20.599614 gettimeofday({973805900, 600195}, NULL) = 0
15:38:20.600798 poll(0xbfffdc64, 0x2, 0, 0x40167520, 0xbfffdc64) = 0
15:38:20.602389 gettimeofday({973805900, 602965}, NULL) = 0
15:38:20.603519 gettimeofday({973805900, 604032}, NULL) = 0
15:38:20.604590 poll(0xbfffdb84, 0, 0, 0x40167520, 0xbfffdb84) = 0
15:38:20.605805 poll(0xbfffdc64, 0x2, 0, 0x40167520, 0xbfffdc64) = 0
...and so on...

Thanks.

-- 
Jeremy M. Dolan <jmd@turbogeek.org>
OpenPGP key = http://turbogeek.org/openpgp-key
OpenPGP fingerprint = 494C 7A6E 19FB 026A 1F52  E0D5 5C5D 6228 DC43 3DEE
--
To unsubscribe, see http://www.squid-cache.org/mailing-lists.html
--
To unsubscribe, see http://www.squid-cache.org/mailing-lists.html