Felix New wrote:
Amos:
thank you very much. i appreciate you if give me some detail.
2008/3/28, Amos Jeffries <squid3@xxxxxxxxxxxxx>:
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
