Re: tomcat java system cpu usage

Hallo Bernd,

Am 2013-12-10 16:30, schrieb Bernd Walter:
> On Tue, Dec 10, 2013 at 03:25:37PM +0100, Marian Hettwer wrote:
>> >>Das verwunderliche was ich sehe ist, daß sobald ich etwas load auf die
>> >>Maschinen gebe, 90% der CPU zyklen auf system cpu verbraucht werden.
>> >>Das ganze system kommt faktisch zum stillstand.
>> >
>> >[...]
>> >
>> >>und system cpu explodiert. :-/
>> >
>> >System CPU im Prozess klingt nach syscall.
>>
>> Ja, wobei 250k bis 300k syscalls/s jetzt nicht sooo viel ist.
>> Also eher langlaufende syscalls.
>
> Naja...
>

Nicht?

>> Bin beim rumsuchen über dtruss gestolpert. Das klingt doch noch mehr
>> nach was ich suche.
>>
>> 5 Sekunden "dtruss -f -c -o -d -p 32754" dann ctrl c gibt mir
>> folgendes:
>>
>> CALL COUNT
[...]
>> pread 12872
>> sched_yield 17521
>>
>>
>> Das war wenn die Maschine bei 50% in load balancing noch ordentlich
>> funktioniert.
>
> Wirklich auffällig sind da in der Anzahl ja nur pread und sched_yield.
>
> pread liest an einer bestimmten Byteposition.
> Das macht vor allem Sinn, wenn sich mehrere Threads einen
> Filedescriptor
> teilen und der globale Positionpointer nicht genutzt werden kann.
> Da steckt einiges an locking im Kernel drin.
> Ich weiß auch nicht wie gut das im Kenel optimiert wurde, aber ich
> bin recht neugierig zu erfahren, ob es was damit zu tun hat, weil
> ich damit auch demnächst einiges anstellen werde, was Performance
> braucht.
>

Tja nun. Ich bin leider kein Kernel Hacker, von daher weiß ich nicht wie
es mit locking rund um pread aussieht.
Falls es von interesse ist, hier sind ein paar dtrace outputs.

http://mon.kernel32.de/dtrace/

gezippt da teilweise recht groß

> Extrem spannend finde ich allerdings die vielen sched_yield.
> Es gibt nur wenig gute Gründe für so einen Aufruf, erst recht nicht,
> wenn man den Scheduler dahinter nicht kennt.
> Man macht das um die CPU von langlaufenden Prozessen, bzw. Threads
> mit niedriger Priorität abzugeben, damit die anderen, die mit
> wenig Latenz möglichst früh die CPU bekommen sollen, nicht darauf
> warten müssen, dass die CPU durch das Preemtive Multitasking per Timer
> abgeholt wird.
> Das macht aber mit zunehmender CPU-Anzahl immer weniger Sinn, da man
> bei reichlich Kernen im Prinzip immer einen hat, der gerade frei ist.
> Außerdem ist der yield-Overhead auch nicht zu unterschätzen,
> insbesonders wenn wirklich immer der Thread gewechselt wird, was je
> nach
> Scheduler und Nutzung durchaus sein kann.
> 17521 in 5 Sekunden sind auch alle 285 Microsekunden ein Taskwechsel.
> Ich weiß nicht wie viele Threads das jetzt machen, aber der Timer
> kommt inzwischen default alle 1ms um die Ecke.
>
Apropos, wenn ich dtruss benutze scheint das auch recht viele
ressourcen zu futtern. Vielleicht sind die Mengen an sched_yield aufrufe
damit verbunden.
Hier mal ein top snapshot wenn dtrace läuft:

   PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU
COMMAND
13518 root 2 38 0 82424K 28940K wait 28 0:23 88.18%
dtrace
12977 www 99 21 0 4859M 417M uwait 13 0:57 34.62%
java

Vielleicht sollte ich doch lieber ktrace/dump benutzen anstelle von
dtruss...

-- 
the problem with troubleshooting is that trouble shoots back.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message