[squid-users] squid cpu usage

[Alex Rousskov]

On 10/26/2017 05:15 AM, Vieri wrote:

> Here's the strace (compressed with gz):
> Do you see anything useful in the trace?

FWIW, nothing jumped at me. As you know, I was asking for a gdb
backtrace, but I no longer think that it is likely to help at this
stage: Your further comments and strace itself confirm that Squid is
_not_ stuck in some tight loop, consuming 100% of CPU. It may be
consuming a lot of CPU cycles, but it is not doing the same compact
operation over and over again, so random gdb backtraces are unlikely to
pinpoint the culprit (if there is one).


> If not, how can I improve the trace next time I have this issue?

Please add (relative) timestamps between system calls (strace -r). It
may help detect periods of time when Squid was not making any system
calls. If possible, I would also add time spend in each system call
(strace -T), just in case, but it is unlikely to be useful in this case.

Please also report how many request did Squid finished handling during
the traced period. You can run mgr:info before/after and/or count
access.log lines.

For mgr:info snapshots, please consider doing the legwork to identify
potentially relevant entries that have changed between the snapshots. I
do not have time to do that (but others on the list might, of course).

I would not bother with mgr:mem snapshots unless mgr:info shows that the
memory has grown a lot during the 100% CPU usage.

Finally, consider enabling Squid debugging for a few seconds of that
100% CPU usage period. Wiki has instructions revolving around sending
Squid a debug signal.


> Having a backup Squid is not that simple in my scenario

It rarely is!


> I didn't run mgr:events while the CPU was at 100%

Please run mgr:events all the time (e.g., every minute) so that you can
catch event(s) (if any) that _lead_ to the 100% CPU usage period. You
can also run mgr:events more often (e.g., every 5 seconds) during the
100% CPU usage period, of course.


HTH,

Alex.