Re: tomcat java system cpu usage

On Tue, Dec 10, 2013 at 03:25:37PM +0100, Marian Hettwer wrote:
> Hallo Bernd (und Lars),
>
> Am 2013-12-10 12:55, schrieb Bernd Walter:
> >On Tue, Dec 10, 2013 at 11:47:12AM +0100, Marian Hettwer wrote:
> >>Hallo Liste,
> >>
> >>ich vermute zwar, daß ich am Ende an freebsd-java@ oder
> >>freebsd-stable@
> >>schreiben muss, aber ich probiers erstmal hier :)
> >>
> >>ich teste auf Arbeit gerade FreeBSD mit java.
> >>Der Cluster in Frage besteht bis jetzt aus 18 Debian Maschinen (Linux
> >>3.2) und meine Versuchskiste wäre die 19. Maschine.
> >>Die Kisten sind das Suchbackend einer der größten deutschen
> >>kleinanzeigen plattformen.
> >>Die Referenzmaschinen (also der bestehende cluster) läuft mit Oracle
> >>Java 7u21, tomcat6 und solr 4.6.0.
> >>Mein Setup der FreeBSD Maschine ist so identisch wie möglich (OpenJDK
> >>7u25 aus packages installiert, ebenso tomcat6).
> >>FreeBSD ist 9.2-REL mit zfs on root (via mfsbsd installiert).
> >>
> >>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...

> 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
> connect 1
> fstat 1
> getsockopt 1
> kqueue 1
> mprotect 1
> open 1
> socket 1
> dup2 2
> getsockname 2
> accept 3
> poll 3
> close 4
> fcntl 7
> setsockopt 9
> sendto 11
> stat 12
> recvfrom 23
> read 38
> ioctl 39
> write 41
> kevent 83
> _umtx_op 191
> 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.

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.

> Mal schauen was für output es gibt wenn sie "umfällt."
>
> Beste Grüße,
> Marian
> --
> the problem with troubleshooting is that trouble shoots back.

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message