Re: [squid-users] cpu load boom when rotate the access.log(coss filesystem)

From: Amos Jeffries <>
Date: Wed, 02 Apr 2008 16:32:50 +1300

Felix New wrote:
> Amos:
> thank you very much. i appreciate you if give me some detail.
> 2008/3/28, Amos Jeffries <>:
>> Ah a few problems with COSS. Firstly it does not handle large objects
>> very well.
>> Secondy its reload requires reading into memory the entire cache_dir
>> slice by slice. Which is extremely slow the larger the dir.
>> You would get better performance splitting your cache into two
>> cache_dirs one COSS (max around 2GB) for small objects and one ufs/aufs
>> for large objects.

Sorry I was out by an order of magnitude. I should have said 20GB.

The 2.6 config manual mentions the default is 8GB

> my every cache_dir disk capability is lager than 100G, and the cache
> box is server for very small files--this is the reason why i use COSS.
> as your advice, i need split the cache into about 50(or more)
> cache_dirs and several aufs for large objects( if exists) this?
> why it can get better performance splittint big cache into several cache_dirs?

With several cache_dir's you have a few factors increasing performance:

  - parallel dir access. As one dir is reading/writing its slices
another could still be used. Usually minor, but under heavy load or very
large caches it can add up.

  - COSS has limited max-size for slices and its dir size.

  - Since COSS apparently must index its whole cache_dir before use,
smaller sizes can reduce the delay before connections are accepted
through the first cache_dir.

  - I don't know much of the details of COSS, but I keep hearing people
mentioning a limit to the file size it likes (a few MB). Using another
cache_dir type can ease that bottleneck.


Please use Squid 2.6STABLE19 or 3.0STABLE3
Received on Tue Apr 01 2008 - 21:32:41 MDT

This archive was generated by hypermail 2.2.0 : Thu May 01 2008 - 12:00:03 MDT