>From documentation:
TC6:
Duration of a poll call. Lowering this value will slightly decrease latency
of connections being kept alive in some cases, but will use more CPU as more
poll calls are being made. The default value is 2000 (5ms).
TC7:
Duration of a poll call in microseconds. Lowering this value will slightly
decrease latency of connections being kept alive in some cases , but will
use more CPU as more poll calls are being made. The default value is 2000
(2ms).
TC6 APR connector defaults are also microseconds. But it gives not 5ms, but
some arbitrary value that depends on kernel configuration. On distribution
default kernels (debian, redhat...) with 100HZ configs ( very common on
servers ) it gives epoll time of 10ms ( sounds reasonable, but... ). Now
where trouble starts is on kernels with NO_HZ and HPET timers - it actually
gives epoll time of 2ms.
The problem is that on reasonably loaded servers tomcat java processes start
to dominate wake up reasons and timer interrupt reasons - waking up each
thread with APR connector ~480 times per second.
pidstat -t -w -C java 1
will show those threads and ~480 context switches they are causing.
and you can confirm the reason for those wakeups with:
gdb -batch -ex bt -p 4056
warning: process 4056 is a cloned process
[Thread debugging using libthread_db enabled]
0x00007f652a096623 in epoll_wait () from /lib/libc.so.6
#0 0x00007f652a096623 in epoll_wait () from /lib/libc.so.6
#1 0x00007f6521147ca3 in ?? () from /usr/lib/libapr-1.so.0
#2 0x00007f6521146908 in apr_pollset_poll () from /usr/lib/libapr-1.so.0
#3 0x00007f652196b2b3 in Java_org_apache_tomcat_jni_Poll_poll
(e=0x40fbf9c8, o=<value optimized out>, pollset=1092883016, timeout=2000,
set=0x7f651b622750,
remove=1 '\001') at src/poll.c:311
Also if you do strace -r -p APRconnectorpid, you will see that there is a
mass of epool_wait calls going on, most of them each doing absolutely
nothing.
Does Tomcat APR really needs pollTime set so low by default? I thought
timeout is meant for some sort of book keeping, where is all connections in
FD set are "idle", no events come for timeout period - you force timeout and
do bookkeeping - on a busy system you will get events anyway cause of socket
traffic. Also connection timeout is 60s by default, so ending connection @
2ms precision is not enhancing latency in any way.
I think defaults should be increased to something reasonable like 100ms
(pollTime ="100000") to avoid unneeded wakeups (and wakeups are bad, cause
they cause context switch, and context switches pollute caches, TLB buffers
and on modern servers burn electricity by forcing CPUs from low C states )
P.S. There exists perfect workaround in latest Tomcat7, using
protocol="org.apache.coyote.http11.Http11NioProtocol" and
protocol="org.apache.coyote.ajp.AjpNioProtocol" for AJP will do away with
all unneeded context switches.
--
View this message in context:
http://old.nabble.com/APR-connector-pollTime-defaults-are-strange-in-tomcat6-7-tp32085364p32085364.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
