On 10/05/2014 6:19 a.m., Fernando Lozano wrote:
> Hi Amos, (or do you prefer Jeffries?)
>> On 9/05/2014 6:29 a.m., fernando wrote:
>>> I have a server configured to run in SMP mode with two cache stores: a
>>> shared rock store and a dedicated aufs store for each worker. But I have
>>> only one physical disk (actually a hardware raid).
>> RAID ? ... pretty much "dont".
> I know... but right now I can't change that. :-( So I'm trying to do the
> best with what I have, and later try to build a new server more closely
> following best practices.
>
>
>> This does not change with SMP. I fact it gets worse as each worker will
>> be adding I/O contention at much higher overall rate than a single Squid
>> process could.
> The problem is: we have lots and lots of acls, and cpu use is already at
> 100% during regular user load. Response time is good, but we can't add
> more acls (and other requested features, such as delay pools) because of
> the cpu bottleneck.
>
Since you have 3.4 version are you making use of the new any-of and
all-of ACLs to build these many ACLs into a tree structure of tests? It
could help reduce the number of ACL tests being done.
If you are able to share the full config + data files (even privately)
perhapse I can assist reducing those ACLs a bit. Although allowing Squid
to process even more traffic might make the disk issues more of a
problem relatively.
Regarding delay pools. I recommend not even bothering. QoS in the
networking stack instead is far more efficient than what Squid does.
>
>> I would take a good look over that hardware RAID controller and see if
>> there is either a way to expose the underlying HDD as mounts for Squid
>> use (effectively disabling the RAID), or pin a particular Squid worker
>> process to a physical spindle (random guess at that even being possible).
> The single raid set has the OS and cache_dir. I can't change that
> without reinstalling anew. And I can't reinstall right now. :-( I wan't
> the guy who installed this firsttime. I'm just expect to do miracles
> with minimum change to the hw/os setup. ;-)
>
>> You dont mention a Squid version, so another thing to look at might be
>> the upcoming large file support for rock caches in 3.HEAD packages. That
>> should (in theory a least) let you replace the AUFS dirs with rock dirs.
> I'm following that. I'm using the latest 3.4.3 RPMs for CentOS by Eliezer.
>
> Policy here won't allow me to try development releases, so I'd have to
> wait for a stable 3.5.x release.
:-( darn. Miracles indeed.
Amos
Received on Fri May 09 2014 - 18:56:31 MDT
This archive was generated by hypermail 2.2.0 : Sat May 10 2014 - 12:00:06 MDT