[squid-users] Rock Store max object size 3.5.14

[Amos Jeffries]

[ pPS please dont hijack other peoples threads ... this has nothing to
do with YouTube ]

On 24/02/2016 8:11 a.m., Heiler Bemerguy wrote:
> 
> Thanks Alex.
> 
> We have a simple cache_dir config like this, with no "workers" defined:
> cache_dir rock /cache2 80000 min-size=0 max-size=32767
> cache_dir aufs /cache 320000 96 256 min-size=32768
> 
> And we are suffering from a 100% CPU use by a single squid thread. We
> have lots of ram, cores and disk space..

Squid is essentially single-threaded (not completely, so dual-core has
benefit, but close). Without SMP enabled you will not benefit from those
"lots of cores".


> but also too many users:
> Number of clients accessing cache:      1634
> Number of HTTP requests received:       3276691
> Average HTTP requests per minute since start:   12807.1
> Select loop called: 60353401 times, 22.017 ms avg
> 

What GHz rating is each CPU core?  200-250 RPS is roughly in the range I
would expect from a 1.xGHz core going full speed / 100% usage.

Are you using RAID on the disk storage? IME, RAID can more than halve
the speed of the proxy. Although the CPU thrashing effect is mostly
hidden away out of sight in the disk controller processor(s).


> Getting rid of this big aufs and spreading to many rock stores will
> improve things here? I've already shrunk the acls and patterns/regexes etc
> 

YMMV but I doubt it. AUFS has 64 disk I/O threads taking advantage of
those other cores. Without SMP rock is restricted to fewer threads for
its I/O and most work is being done by the main worker core anyway
without the disk IO portion.


With CPU maxing out as the bottleneck I would be looking at config
perforemance (you say you have done that already), then Squid SMP
workers as the next workaround. With disk efficiencies later if/when
they become relevant.

Amos