<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>I checked the bug you have mentioned and I think I am confronted with the same issue. I was able to build and test Squid 3.5.6 on Ubuntu 14.04.2 x84_64. I observed the same behavior. I have tested an 8 GB archive file and I get 100 % CPU usage and a download rate of nearly 500 KB/sec when the object gets cached. I have attached strace to the running process, but I killed it after 30 minutes. The whole takes hours, although we have a 1-GBit ethernet:<br/>
<br/>
Process 4091 attached<br/>
Process 4091 detached<br/>
% time seconds usecs/call calls errors syscall<br/>
------ ----------- ----------- --------- --------- ----------------<br/>
78.83 2.622879 1 1823951 write<br/>
12.29 0.408748 2 228029 2 read<br/>
6.18 0.205663 0 912431 1 epoll_wait<br/>
2.58 0.085921 0 456020 epoll_ctl<br/>
0.09 0.002919 0 6168 brk<br/>
0.02 0.000623 2 356 openat<br/>
0.01 0.000286 0 712 getdents<br/>
0.00 0.000071 1 91 getrusage<br/>
0.00 0.000038 0 362 close<br/>
0.00 0.000003 2 2 sendto<br/>
0.00 0.000001 0 3 1 recvfrom<br/>
0.00 0.000000 0 2 open<br/>
0.00 0.000000 0 3 stat<br/>
0.00 0.000000 0 1 1 rt_sigreturn<br/>
0.00 0.000000 0 1 kill<br/>
0.00 0.000000 0 4 fcntl<br/>
0.00 0.000000 0 2 2 unlink<br/>
0.00 0.000000 0 1 getppid<br/>
------ ----------- ----------- --------- --------- ----------------<br/>
100.00 3.327152 3428139 7 total<br/>
<br/>
Can I do anything that helps to get ride of this problem?<br/>
<br/>
<br/>
Gesendet: Dienstag, 21. Juli 2015 um 17:37 Uhr<br/>
Von: "Amos Jeffries" <squid3@treenet.co.nz><br/>
An: "Jens Offenbach" <wolle5050@gmx.de>, "squid-users@lists.squid-cache.org" <squid-users@lists.squid-cache.org><br/>
Betreff: Re: Aw: Re: [squid-users] Squid3: 100 % CPU load during object caching<br/>
On 22/07/2015 12:31 a.m., Jens Offenbach wrote:<br/>
> Thank you very much for your detailed explainations. We want to use Squid in<br/>
> order to accelerate our automated software setup processes via Puppet. Actually<br/>
> Squid will host only a very short amount of large objects (10-20). Its purpose<br/>
> is not to cache web traffic or little objects.<br/>
<br/>
Ah, Squid does not "host", it caches. The difference may seem trivial at<br/>
first glance but it is the critical factor between whether a proxy or a<br/>
local web server is the best tool for the job.<br/>
<br/>
>From my own experiences with Puppet, yes Squid is the right tool. But<br/>
only because the Puppet server was using relatively slow python code to<br/>
generate objects and not doing server-side caching on its own. If that<br/>
situation has changed in recent years then Squids usefulness will also<br/>
have changed.<br/>
<br/>
<br/>
> The hit-ratio for all the hosted<br/>
> objects will be very high, because most of our VMs require the same software stack.<br/>
> I will update mit config regarding to your comments! Thanks a lot!<br/>
> But actually I have still no idea, why the download rates are so unsatisfying.<br/>
> We are sill in the test phase. We have only one client that requests a large<br/>
> object from Squid and the transfer rates are lower than 1 MB/sec during cache<br/>
> build-up without any form of concurrency. Have vou got an idea what could be the<br/>
> source of the problem here? Why causes the Squid process 100 % CPU usage.<br/>
<br/>
I did not see any config causing the known 100% CPU bugs to be<br/>
encountered in your case (eg. HTTPS going through delay pools guarantees<br/>
100% CPU). Which leads me to think its probably related to memory<br/>
shuffling. (<<a href="https://3c.gmx.net/mail/client/dereferrer?redirectUrl=http%3A%2F%2Fbugs.squid-cache.org%2Fshow_bug.cgi%3Fid%3D3189" target="_blank">http://bugs.squid-cache.org/show_bug.cgi?id=3189</a>> appears<br/>
to be the same and still unidentified)<br/>
<br/>
As for speed, if the CPU is maxed out by one particular action Squid<br/>
wont have time for much other work. So things go slow.<br/>
<br/>
On the other hand Squid is also optimized for relatively high traffic<br/>
usage. For very small client counts (such as under-10) it is effectively<br/>
running in idle mode 99% of the time. The I/O event loop starts pausing<br/>
for 10ms blocks waiting to see if some more useful amount of work can be<br/>
done at the end of the wait. That can lead to apparent network slowdown<br/>
as TCP gets up to 10ms delay per packet. But that should not be visible<br/>
in CPU numbers.<br/>
<br/>
<br/>
That said, 1 client can still max out Squid CPU and/or NIC throughput<br/>
capacity on a single request if its pushing/pulling packets fast enough.<br/>
<br/>
<br/>
If you can attach the strace tool to Squid when its consuming the CPU<br/>
there might be some better hints about where to look.<br/>
<br/>
<br/>
Cheers<br/>
Amos<br/>
</div></div></body></html>