[ 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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
