<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    -----BEGIN PGP SIGNED MESSAGE----- <br>
    Hash: SHA256 <br>
     <br>
    The rule is simple.<br>
    <br>
    If threads on processor(s) are in the queue to the disk - the
    bottleneck is disk.<br>
    If the disks or network interfaces (IO threads) waits execution on
    processor(s) - CPU(s) bottleneck.<br>
    <br>
    PS. And, man, 1600 users is not a high load. Really high load
    starting with 15-30k users. ;)<br>
    <br>
    24.02.16 2:04, Yuri Voinov пишет:<br>
    <span style="white-space: pre;">><br>
      > Agreed.<br>
      ><br>
      > High-load big enough caches must utilize _an adequate_
      hardware<br>
      > configuration with enough capacity to meet you expectations.<br>
      ><br>
      > And, of course, cache software configuration must fit this
      hardware, to<br>
      > maximize approaches.<br>
      ><br>
      > 24.02.16 1:55, Amos Jeffries пишет:<br>
      > > [ pPS please dont hijack other peoples threads ... this
      has nothing to<br>
      > > do with YouTube ]<br>
      ><br>
      > > On 24/02/2016 8:11 a.m., Heiler Bemerguy wrote:<br>
      > >><br>
      > >> Thanks Alex.<br>
      > >><br>
      > >> We have a simple cache_dir config like this, with no
      "workers" defined:<br>
      > >> cache_dir rock /cache2 80000 min-size=0
      max-size=32767<br>
      > >> cache_dir aufs /cache 320000 96 256 min-size=32768<br>
      > >><br>
      > >> And we are suffering from a 100% CPU use by a single
      squid thread. We<br>
      > >> have lots of ram, cores and disk space..<br>
      ><br>
      > > Squid is essentially single-threaded (not completely, so
      dual-core has<br>
      > > benefit, but close). Without SMP enabled you will not
      benefit from those<br>
      > > "lots of cores".<br>
      ><br>
      ><br>
      > >> but also too many users:<br>
      > >> Number of clients accessing cache:      1634<br>
      > >> Number of HTTP requests received:       3276691<br>
      > >> Average HTTP requests per minute since start:  
      12807.1<br>
      > >> Select loop called: 60353401 times, 22.017 ms avg<br>
      > >><br>
      ><br>
      > > What GHz rating is each CPU core?  200-250 RPS is
      roughly in the range I<br>
      > > would expect from a 1.xGHz core going full speed / 100%
      usage.<br>
      ><br>
      > > Are you using RAID on the disk storage? IME, RAID can
      more than halve<br>
      > > the speed of the proxy. Although the CPU thrashing
      effect is mostly<br>
      > > hidden away out of sight in the disk controller
      processor(s).<br>
      ><br>
      ><br>
      > >> Getting rid of this big aufs and spreading to many
      rock stores will<br>
      > >> improve things here? I've already shrunk the acls
      and<br>
      > patterns/regexes etc<br>
      > >><br>
      ><br>
      > > YMMV but I doubt it. AUFS has 64 disk I/O threads taking
      advantage of<br>
      > > those other cores. Without SMP rock is restricted to
      fewer threads for<br>
      > > its I/O and most work is being done by the main worker
      core anyway<br>
      > > without the disk IO portion.<br>
      ><br>
      ><br>
      > > With CPU maxing out as the bottleneck I would be looking
      at config<br>
      > > perforemance (you say you have done that already), then
      Squid SMP<br>
      > > workers as the next workaround. With disk efficiencies
      later if/when<br>
      > > they become relevant.<br>
      ><br>
      > > Amos<br>
      ><br>
      > > _______________________________________________<br>
      > > squid-users mailing list<br>
      > > <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
      > > <a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a><br>
      ><br>
      ></span><br>
    <br>
    -----BEGIN PGP SIGNATURE-----
<br>
    Version: GnuPG v2
<br>
     <br>
    iQEcBAEBCAAGBQJWzMJRAAoJENNXIZxhPexGYYkH/jzBXz01wAl3/kvGD75Ya6Nr
<br>
    lmdMX6nVx+3UHPIwC24RJJcJrxaRfHAuXA1NSArvu5iM90O9WDkYcJYLO6FCOeuk
<br>
    qha3eMl+KTcFpk7GunaZNF1G6O/kIS5VymFs0lc9tuz6W1GNUmuvfcVIXCc7XDC5
<br>
    SM6SY/u7gnnRvxhUyYlrLhb7TdS4uQ5HShqBhaMtkAM5LFVLnPAK9rTxEYr2A7Qq
<br>
    hQVkn1lBm/sTImd1fhts3Qkr7F3GDUsOpfmMGeGUIvKCPm9sMTc01trK1Rcb3cre
<br>
    dhuluPvbFCguuxvDRCMvoU6DpEkvZDjNL+kN+gLI5SfrqlcZjb4xRosKt5d18Y0=
<br>
    =i5/S
<br>
    -----END PGP SIGNATURE-----
<br>
    <br>
  </body>
</html>