-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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 iQEcBAEBCAAGBQJWzLthAAoJENNXIZxhPexG2F8IAJvpm++PFSuglu8us998ZSWi u+Lih+wQPXa5YNjb5IHB2M+Hp0v5wFCAYCQZngicXeroeH1Fq1B3nZfVRNBlJkeS 0Uuk/agq4ZD7C54DPA+/rfj69t1dYcf72PGiJ7RcFWG9wZdA096x5SvNN9eWYFZ4 gnvX/KlnVzST972bwBqaklhEorOgJQNt2V19H6tTako2rvU/qk3Fqf+9CmzPD4Ld Y0PsWAu2bgPhu2FvI1+x4UIBOGbmOQncDnll7SXjc+0M0LIUDRhHXK0LnGXR0YWV i1MgPpe5/GxRhK0NhskfgmsSTHRZZuHmIEsfdMvjaNQggourNbu9vfKrs6xqKGw= =CMql -----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
