|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The rule is simple. If threads on processor(s) are in the queue to the disk - the bottleneck is disk. If the disks or network interfaces (IO threads) waits execution on processor(s) - CPU(s) bottleneck. PS. And, man, 1600 users is not a high load. Really high load starting with 15-30k users. ;) 24.02.16 2:04, Yuri Voinov пишет: > > Agreed. > > High-load big enough caches must utilize _an adequate_ hardware > configuration with enough capacity to meet you expectations. > > And, of course, cache software configuration must fit this hardware, to > maximize approaches. > > 24.02.16 1:55, 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 > > > _______________________________________________ > > squid-users mailing list > > squid-users@xxxxxxxxxxxxxxxxxxxxx > > http://lists.squid-cache.org/listinfo/squid-users > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWzMJRAAoJENNXIZxhPexGYYkH/jzBXz01wAl3/kvGD75Ya6Nr lmdMX6nVx+3UHPIwC24RJJcJrxaRfHAuXA1NSArvu5iM90O9WDkYcJYLO6FCOeuk qha3eMl+KTcFpk7GunaZNF1G6O/kIS5VymFs0lc9tuz6W1GNUmuvfcVIXCc7XDC5 SM6SY/u7gnnRvxhUyYlrLhb7TdS4uQ5HShqBhaMtkAM5LFVLnPAK9rTxEYr2A7Qq hQVkn1lBm/sTImd1fhts3Qkr7F3GDUsOpfmMGeGUIvKCPm9sMTc01trK1Rcb3cre dhuluPvbFCguuxvDRCMvoU6DpEkvZDjNL+kN+gLI5SfrqlcZjb4xRosKt5d18Y0= =i5/S -----END PGP SIGNATURE----- |
Attachment:
0x613DEC46.asc
Description: application/pgp-keys
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
