[squid-users] Rock Store max object size 3.5.14

[Yuri Voinov]

-----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 at lists.squid-cache.org
> > 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-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160224/ec49cd74/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x613DEC46.asc
Type: application/pgp-keys
Size: 2437 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160224/ec49cd74/attachment-0001.key>