On Thursday, March 14, 2002, at 04:29 , Joe Cooper wrote:
> This isn't terribly surprising. Squid requires about 10MB or memory
> per GB or cache_dir configured. So if you're using most of that 216GB
> for cache_dirs, you're going to eat all of your memory just dealing
> with the in-core object index, leaving no room for anything else. At
> this time I won't configure anything with more than 108GB of disk space
> (6 x 18GB 15k RPM, to be specific), because Intel boxes can't go over
> 4GB of RAM, and performance would suffer if we used much more than that.
>
> On our 2GB RAM boxes, I configure about 45GB total cache_dir or less.
> Much more than that can lead to performance degradation. If your box
> can handle more memory, you can probably make more use of your disks by
> upgrading RAM.
>
> As for your question "Squid doesn't like disks that large?"...Squid
> doesn't care how big your disks are, but it does have to have enough
> RAM to index them. And because of OS-level disk caching, your box will
> perform better with smaller cache_dir configurations to some extent.
>
> So shrink those partitions a bit, or get some more RAM. It is pretty
> cheap these days, though I don't know if you can use commodity parts in
> your Ultra 250.
>
Thanks, that clears thing up a a lot. With the cache_dir directive -
when squid notices that this value has been reduced, obviously it
shrieks, but does it then start removing objects itself to meet the new
cache_dir value? (if not, what's the quickest/most painless method of
bringing the spool size down to the new cache_dir value? (rm seems a
little aggressive, but is it the best solution or is leaving squid alone
the way to go?)
Received on Thu Mar 14 2002 - 02:52:24 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:06:55 MST