On 18/07/11 21:05, Francesco wrote:
> Hello,
>
> i have got a Squid version 3.1.8 running on a CentOS 5.x.
> Since it works for url and content filtering, in conjunction with
> Dansguardian in front, for some hunderd of users, the load average of that
> machine is sometimes very high (also 5.0 or 8.0...).
Check your config for regex ACLs. They slow squid down. A lot. Simple
tuning such as dstdomain instead of domain regex can raise the req/sec
rates up easily.
> The biggest process is squid, both on CPUs and Memory; i noticed, by
Squid-3 is not very efficient with CPU yet. We are still optimizing that
down after the new feature additions. It also uses RAM cache a lot more.
> entering top -s and press "1" - that often the system is in wait, perhaps
> it waits for the disk IO subsystem to write and manage Squid's cache.
Very likely. Check your disk I/O stats as well.
>
> I tried to make some customization in cache tuning, thinking that the
> bottleneck are disks, so i reduce the cache size.
Okay, confirmation that disk is one of the bottlenecks for you.
>
> Something is getting better, but the system is still very loaded.
>
> Are there some general suggestions to privilege speed and not bandwidth,
> for systems with very high load?
* AUFS cache format on CentOS. This one is specific.
* JBOD configuration spread over more disks. Avoid RAID unless you have
high quality H/W controllers. Squid thrashes the disks with mostly
random-access writes and byte-hit-ratio proportion of random-access reads.
* Faster disks, you can get a good +50% speed out of 15Krpm over 10Krpm
according to the I/O benchmarks from last year.
* Possibly an SSD drive for small objects cache_dir (use min-size and
max-size to tune).
If this is still a big problem after tuning you may want to get in touch
with The Measurement Factory about a build of squid 3.2 with rock
storage. That is the new replacement for COSS and does SMP support as
well as disk backed slices.
Amos
-- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.14 Beta testers wanted for 3.2.0.9Received on Mon Jul 18 2011 - 12:32:43 MDT
This archive was generated by hypermail 2.2.0 : Mon Jul 18 2011 - 12:00:02 MDT