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
