Squid slow during cleanup

From: Martin Gleeson <gleeson@dont-contact.us>
Date: Tue, 10 Sep 1996 16:50:10 +1000

Hi,
    We've recently been encountering problems with squid when it goes
into cleanup mode after passing the cache_swap_high limit. Performance
slows considerably: 10-20 times slower than normal. Examination of cache.log
shows that it is attempting to cleanup the swap area: regular entries of
[..] store_clean.c:98: Cleaned 10 unused files from /servers/http/cache/xx

When it gets into this state, the cache swap area grows faster than squid
can clean it up, and the only solution we've been able to try is to delete
the entire cache and start again from scratch. This involves changing
squid.conf to go into 'proxy-only' mode while the files in the cache_dir
area are deleted, and then changing it back. Funnily enough, doing this
seems to have no real impact on the hit rate from the cache (calculated
over a week).

The performance degradation is a major issue, with over 5,000 local users
generating almost 2 million requests a week, as well as 6 squid neighbours
generating another 4+ million ICP and TCP requests. Users report that the
proxy performance is almost unbearable when it is in this state.

Has anyone else encountered such a problem and have any suggestions?

For reference, our server is a AlphaServer 8200, with 512Mb RAM, 2Gb swap
and the following squid.conf settings:
cache_mem 256
cache_swap 15000
cache_swap_low 75
cache_swap_high 90
cache_mem_low 75
cache_mem_high 95

Cheers,
Marty.
-------------------------------------------------------------------------
Martin Gleeson Webmeister | http://www.unimelb.edu.au/%7Egleeson/
Information Technology Services | Email : gleeson@unimelb.edu.au
The University of Melbourne, Oz. | Phone : +61 3 9344 7407
       "I hate quotations" -- Ralph Waldo Emerson; Journals (1843)
-------------------------------------------------------------------------
Received on Mon Sep 09 1996 - 23:56:45 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:32:58 MST