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

Felix New wrote:
> Amos:
> thank you very much. i appreciate you if give me some detail.
>
>
> 2008/3/28, Amos Jeffries <squid3@treenet.co.nz>:
>> 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
   http://www.squid-cache.org/Versions/v2/2.6/cfgman/cache_dir.html

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

Amos

-- 
Please use Squid 2.6STABLE19 or 3.0STABLE3