Search squid archive

Re: Heavy load squid with high CPU utilization...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



When squid is stop... cpu usage dont go over 5%.
Maybe my conf is problem, but I think it is not...
I have about 6k request per minute so I am confused with this poor performance.
About 1k users access squid in peek with about 80Mbps traffic.

On Sat, 26 Mar 2011 14:06:10 -0700 (PDT), david@xxxxxxx wrote:
In my testing in the last couple of weeks, I've found that newer
squid versions take significantly more cpu than the older versions,
translating into significantly less capacity

I didn't test 2.7, but in my tests

3.0 4200 requests/sec
3.1.11 2100 requests/sec
3.2.0.5 1400 requests/sec (able to scale up to 2900 request/sec using
4 cpu cores, beyond that it dropped again)

David Lang

On Sat, 26 Mar 2011, Dejan Zivanic wrote:

With squid 3.1.11 CPU usage of squid process is 100% during 10am to 10 pm...

I will try now with 2.7.Stable9. I just dont know what could be the problem.



On 23.3.11. 16.24, Marcus Kool wrote:

Zivanic Dejan wrote:

On 3/23/11 3:27 AM, Marcus Kool wrote:
Dejan,
Squid is known to be CPU bound under heavy load and the
Quad core running at 1.6 GHz in not the fastest.
A 3.2 GHz dual core will give you double speed.
The config parameter "minimum_object_size 10 KB"
prevents that objects smaller than 10 KB are not written to disk.
I am curious to know why you have this value and if you
benchmarked it, can you share the results ?
The mean object size is 53 KB and the parameter
maximum_object_size_in_memory 50 KB
implies that you have a relatively large number of hot objects
that do not stay in memory.
The memory hit % is low and the disk hit % is high, so the
maximum_object_size_in_memory should be increased.
I suggest 96 KB, monitor the memory hit % and increase more
if necessary.

increased

client_persistent_connections and server_persistent_connections
are off.  The default is on and usually gives better performance.
Why are they off ?
changed
The TCP window scaling is off.  This is a performance penalty
for large objects since it uses the select/epoll loop a lot more
because objects arrive in more smaller pieces.
Why is it off ?
I activate scaling.

If you have a good reason to set it off I recommend to use
the maximum size for fixed TCP window size: 64K (squid parameter
tcp_recv_bufsize) to reduce the number of calls to select/epoll.

with scaling on should i set tcp_recv_bufsize to 64k ?
Your TCP scaling options are:
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 87380 16777216
No. with scaling your settings are ok although the maximum values are a bit high. To save memory, you could set tcp_recv_bufsize to anything reasonable.
This depends mostly on average delay.

You use one disk solely for cache.  This can be better
if you use a battery-backed disk I/O controller with
256MB cache.
And the obvious: more disks is good for overall performance
Marcus
Of course, I am interested in feedback and what the configuration changes
mean for the performance.
Marcus






[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux