Re: Squid slow during cleanup

- 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.
-
- 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

        You need a lot more disk is the short answer. Allowing squid to get to
garbage collection mode is a performance killer as you have found.

        Failing the sudden acquistion of more disk drives I suggest you
reduce the default retention times.

# Access Type Max Object Size TTL (note: 10080 minute = 1 week)
# --------- ---------------- -----------
#gopher 4 10080
#http 4 10080
#ftp 4 10080

        I dont know what times you have set, but whatever it is you need to reduce
it. Reducing the maximium object size can help as well

        Creative use of ttl_pattern can help here, a short lifetime on all
those .gif's, jpeg's & mpeg's can do wonders.

        "quick_abort on" will stop those that visit a page, start a
download, abort it, go somewhere else, come back later when it is in the
proxy cache and is only a local download for them.

        You could consider using acl & http_access to block accesses to the
more popular sex sites, though that would push up your international
bandwidth usage as they turned off the proxy settings to get there.

        The above stuff is the obvious things to do (at least for me), but
this will get them out of the way and others can add their "obvious" fixes.

        You could change cache_swap_low & cache_swap_high to 90 & 95 respectively.
This will eek out a little more disk space for you.
Maybe only change cache_swap_high to 95%.

PS: You haven't told us which version of squid you are running. I was
    going to comment on your cache_mem setting being high but remembered
    that its menaing changed somewhere after the 1.0beta's

-- 
Neil Murray                              Email:  neil@aone.com.au
Access One Pty. Ltd.                     http://www.aone.net.au/
41 Malcolm Rd., Braeside                 Phone:  +61 3 9239 1444
Victoria, Australia  3195                Fax:    +61 3 9580 5581