2006-01-03 16:42:08

by Ian Blanes

Subject: high system load on tcp_poll and tcp_sock in 2.6 caused by squid

Hi,

I'm getting this report from oprofile from a squid server with about 2000
clients. I'm not sure if this is normal... any idea on where to look?

thanks
ian

Cpu0 : 20.0% us, 43.3% sy, 0.0% ni, 20.1% id, 15.8% wa, 0.9% hi, 0.0%
si

SElinux compiled but dissabled. Tested on smp kernel and on single
processor kernel. P4 2.40GHz, HT dissabled, e1000 network card, using
multiple(4) ip address on the same card.

(other event types gave similar results)
CPU: CPU with timer interrupt, speed 0 MHz (estimated)
Profiling through timer interrupt
samples % app name symbol name
87849 28.0555 vmlinux default_idle
70392 22.4804 vmlinux tcp_poll
36378 11.6177 vmlinux sock_poll
24749 7.9038 squid clientReadRequest
14889 4.7550 vmlinux fget
6408 2.0465 vmlinux fput
5841 1.8654 squid _db_init
3996 1.2762 vmlinux remove_wait_queue
3757 1.1998 squid httpHeaderEntryCreate
2953 0.9431 squid ctx_print
2268 0.7243 squid comm_poll
2106 0.6726 e1000 (no symbols)
2077 0.6633 vmlinux add_wait_queue
1648 0.5263 vmlinux handle_IRQ_event
1625 0.5190 vmlinux do_pollfd
1500 0.4790 libc-2.3.4.so memcpy
1309 0.4180 squid _db_print
1074 0.3430 squid mime_get_auth
1039 0.3318 squid peerAllowedToUse
[...]

2006-01-03 17:08:21

by Patrick McManus

Subject: Re: high system load on tcp_poll and tcp_sock in 2.6 caused by squid

On Tue, 2006-01-03 at 17:43 +0100, Ian Blanes wrote:
> Hi,
>
> I'm getting this report from oprofile from a squid server with about 2000
> clients. I'm not sure if this is normal... any idea on where to look?
>
> thanks
> ian
>
> Cpu0 : 20.0% us, 43.3% sy, 0.0% ni, 20.1% id, 15.8% wa, 0.9% hi, 0.0%
> si

oh that's going to be quite normal for any poll driven application with
a lot of concurrent connections.. think about what poll() does - it
scans all 2000 sockets and returns to you the set of ones that have
something to do.. assuming a small fraction of them meet that criteria
it does just a little work to satisfy their needs and then repeats the
process..

the epoll() style interface that is also in the kernel lets the
application essentially get change events instead of doing that big
repeated scan.. its much more efficient but it needs to be supported by
the application.