[squid-users] Squid 3.5.21 - High CPU (100%)

[Jasper Van Der Westhuizen]

On Wed, 2016-09-21 at 08:34 -0600, Alex Rousskov wrote:

On 09/21/2016 07:53 AM, Jasper Van Der Westhuizen wrote:


I have been having some problems with Squid using
100% CPU at times which impacts my users browsing experience.



Sustained 100% CPU load at ~100/s rates with regular traffic on
reasonable hardware is a sign (albeit not a proof!) of a Squid bug
(including long searches and similar optimization problems).


I seem to have gotten better results/performance by doing some config changed. I removed a whole bunch of pattern_refresh lines and replaced them with better formulated lines.








During the last time I had a proxy servers CPU reach 100% I ran a
cachemgr export and below is an extract.



Next time this happens, consider getting a stack trace or two from the
process showing sustained 100% CPU utilization. It is possible to do
that without killing the processes (at least on Linux). I do not have
step-by-step instructions, but you can find them. Make sure you run (or
at least use for getting the stack trace?) an unstripped Squid binary,
preferably built with --disable-optimizations.

If the place where Squid gets stuck is known, somebody may volunteer to
fix the corresponding code.



I do not have much experience with strace. What I found now after making changes to my squid.conf file, my cache drive gets *hammered* at times of high usage. Especially in the morning when all the users come online. I have huge amounts of writes happening and this creates CPU wait and the user experience goes out of the window. My proxies are VM's with separate drives for the cache, running on reiserfs(previously EXT3). My L1 and L2 directory structure is 32 and 256 respectively with the aufs store type. In my VMWare cluster I see high write latency to the cache disks.

Is there anything that you guys can suggest I do around the cache? Should I try a different store type? A different filesystem type perhaps?

Kind Regards
Jasper




Disclaimer:
http://www.shopriteholdings.co.za/Pages/ShopriteE-mailDisclaimer.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160926/b27b64ee/attachment.html>