[JAVA] Hoher Sys-Load, woher?

[c. m. (Gast)]

Ich bin grade dabei eine Java-Anwendung zu schreiben die mehrere (hier 
24) Threads startet um Dokumente mit Apache FOP zu erzeugen.

Das grobe Gerüst ist:
Ein Thread hat eine Liste (ArrayList oder Vector, beides probiert), und 
stellt eine synchronized Methode getNextDocument() bereit.
Die (24) Generatorenthreads rufen getNextDocument() in einer loop in 
ihrer jeweiligen run() Methode, sind bei der Bearbeitung des Datenpakets 
350-500ms beschäftigt, updaten dabei Datenfelder im Objekt das mit 
getNextDocument() geliefert wurde, und wenn sie fertig sind rufen sie 
wieder getNextDocument() bis der Aufruf null zurück gibt.
Während dieser Zeit gibt es keine Netzwerk- oder Dateisystemzugriffe - 
das Programm hat alle Daten im RAM und verarbeitet sie.

Jetzt stößt mir ein wenig bitter auf, dass die Prozesse so viel Sys-Load 
machen. User-Load wäre so weit ich das verstanden habe ok - dann macht 
das Programm was, aber Sys-Load bedeutet doch Kontext-Switches, 
Speicherallokierung, oder anders gesagt: Zeit die der Kernel braucht, 
und die dem Programm nicht zur Verfügung steht.
Dazu kommt das ich mich nicht erinnern kann den gleichen Sys-Load im POC 
Progrämmchen zu haben - das auch schneller mehr Dokumente erzeugte.
Irgendwie irgendwo hat sich beim schreiben des eigentlichen Programms 
ein Fehler eingeschlichen, der mir ordentlich Performace klaut… nur… wo?

Anbei Bildchen:
1. htop Anzeige der Prozessorbelastung. Grün ist OK, User-Land, rot ist 
böse.
2. dstat zeigt htop kumuliert. Auffällig sind die vielen Interrupts.
3. irqstats. Hier gehen bei der Generierung die "Local Timer 
Interrupts", und die "TLB Shootdowns" hoch. Liegt hier das Problem? Wenn 
ja, welcher Teil von Java macht sowas? Analysemöglichkeit? Lösung?
4. VisualVM Trace während des Programmablaufs (RAM Rampe am Anfang ist 
"Daten holen", der Rest ist "Generierung" mit den beschriebenen 
Symptomen).  Auffällig hier: Es kann nicht am GC liegen, der dümpelt nur 
so vor sich hin.

Kann mir da jemand weiter helfen? Schon mal ähnliche Probleme gehabt?

[Dirk D. (dicky_d)]

Da kämpfen 24 Threads um die volle Aufmerksamkeit der CPU, das geht für 
gewöhnlich nicht ohne Reibungsverluste.

[Wühlhase (Gast)]

Warum so viele Threads zum Dokumente-Erstellen?

Netbeans hat doch einen Profiler dabei, mit dem man Leistungslecks 
aufspüren können soll. Ich hab den noch nie genutzt, bisher hat mich die 
Performance meiner Java-Spielereien noch nie interessiert, aber den würd 
ich mir mal zu Gemüte führen.

[c.m. (Gast)]

Dirk D. schrieb:
> Da kämpfen 24 Threads um die volle Aufmerksamkeit der CPU, das geht für
> gewöhnlich nicht ohne Reibungsverluste.

ja, 24 Threads "kämpfen" auf "der CPU" mit 32 Threads…
"reibungsverluste" erwarte ich auch da natürlich, aber nicht im hohen 
2-stelligen prozentbereicht, weil der "kampf" der generatorenthreads um 
"die aufmerksamkeit" nur an der synchronisierten 
getNextDocument()-methode stattfindet, die im sub-millisekunden bereich 
einen counter hochzählen, und eine objektreferenz zurückliefern können 
sollte.

Wühlhase schrieb:
> Warum so viele Threads zum Dokumente-Erstellen?

weils viele dokumente sind - so 50k pro lauf.

> Netbeans hat doch einen Profiler dabei, mit dem man Leistungslecks
> aufspüren können soll. Ich hab den noch nie genutzt, bisher hat mich die
> Performance meiner Java-Spielereien noch nie interessiert, aber den würd
> ich mir mal zu Gemüte führen.

hast du bei deinen spielereien mal ausprobiert, ob der netbeans-profiler 
detailliertere daten liefert als visualVM? kann man den remote, z.b. per 
JMX, auf eine laufende javaVM aufschalten?

<motzmode>
anscheinend hat schon wieder niemand irgendwas ähnliches gemacht, oder 
hatte nie derartige probleme.
ich hab den gleichen mist gestern in ein dediziertes java-forum 
gepostet, und da kommt auch nur 08/15 BS. *grrrr
</motzmode>

[Zusammenhang`? (Gast)]

https://perf.wiki.kernel.org/index.php/Main_Page

[Zusammenhang`? (Gast)]

Und strace(1) könnte auch weiterhelfen.

[Zusammenhang`? (Gast)]

c. m. schrieb:
> Auffällig hier: Es kann nicht am GC liegen, der dümpelt nur
> so vor sich hin.

GC braucht User, kein Sys.

[c.m. (Gast)]

Zusammenhang`? schrieb:
> https://perf.wiki.kernel.org/index.php/Main_Page

mit strace und perf ist mir aber im endeffekt auch nicht geholfen, weil 
die zwar zeigen welche zugriffe ich habe, und wie lang das programm/die 
CPUs beschäftigt sind, aber eben nicht woher im programm die last kommt.


jedoch… HEUREKA! ich habs gefunden.
ich hab wühlhases vorschlag umgesetzt und den netbeans-profiler statt 
visualvm benutzt - und ja, der kann auch remote verbindungen. sehr 
schön.

das problem war, dass das test-XSLT einen font benutzen will, der nicht 
im standard-repertoire von PDF definiert ist, und FOP in seiner 
config-datei so konfiguriert war, dass er bei unbekannten Fonts das 
Betriebssystem nach passenden font-files durchsucht.
resultat war, dass die generatorenthreads ein paar 100ms damit 
beschäftigt waren, verzeichnisstrukturen abzugrasen (siehe bild).

ty an alle :)