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?
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.
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`? 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 :)
Eine eigene Frage?
Dieser Thread ist über 9 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
htop.png
(110 KB)
dstat.png
(79 KB)
irqstats-day.png
(160 KB)
VisualVM.jpg
(98 KB)
