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?
Da kämpfen 24 Threads um die volle Aufmerksamkeit der CPU, das geht für gewöhnlich nicht ohne Reibungsverluste.
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>
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.
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 :)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.