schlechte Java-Performance

[lrmeyer]

Hallo zusammen.

Wer kennt sich mit Java und möglichen Tuning-Maßnahmen aus?

Wir haben das Problem, das die bei uns eingesetzten Java-Programme eine sehr schlechte Performance haben. Wir benutzen z.B. ein Programm zum kopieren von Spool-Dateien in ein PDF-Format. Das kopieren dauert geschlagene 3 Stunden. Auch das Optimieren bei der Erstellung des Java-Programmes auf 30 bzw. 40 hat nichts gebracht. Ebenso wollen wir Lieferschein-Avise mittels Java über SMTP an unser Mail-System senden. Auch hier haben wir eine sehr schlechte Performance. Das senden einer einzigen E-Mail dauert 10 Minuten!

Auf unserer Maschine ist V4R4 mit dem letzten Cum-Tape installiert.

Hat jemand eine Idee?


Lars

[Günther]

Hallo Lars,

ich bin zwar kein Java-Spezialist, aber nach allem was man so liest, ist ja bekannt, daß Java langsam ist; zudem wurde dieser Tatsache bei der AS/400 mit schnelleren Prozessoren und neuen Releases begegnet;
von daher meine ich, V4R5 sollte zumindest installiert werden; was habt ihr für eine Maschine ? was bedeutet Einstellung 30 oder 40 ?

Mfg Günther

[lrmeyer]

Hallo,

mit 30 oder 40 meine ich, das man im Befehl CRTJVAPGM einen Parameter setzen kann, ob das Programm mit OPTIMIZE 30 bzw. 40 umgewandelt werden soll. Je höher der Wert ist, umso besser soll die Performance bzw. Optimierung sein.

Wir haben als Maschine eine 9406/170-2292.

Lars

[lrmeyer]

Hallo nochmal,

wichtig ist in diesem Zusammenhang noch zu erwähnen, das die einzelnen Java-Jobs selbst nicht einmal 1% CPU-Auslastung haben, also den Prozessor an sich kaum belasten.

Lars

[schreibr]

Hallo Lars,
in einer anderen Newsgroup habe ich folgenden Beitrag gefunden:
---------------------------------------------
Grundsätzlich gilt für Java-Datenbankzugriffe eine sehr viel schlechtere
Performance.

Wenn auf der AS/400 ein Batch-Job in RPG oder in Java läuft, dann benötigt
der Java-Job schon leicht die 20-fache Laufzeit - also nicht gerade geeignet,
um GIGA-Bytes auf die AS/400 zu schaufeln.


Eine Lösung mit ausreichender Performance könnte man z.B. mit einem VA RPG
Programm erreichen, das per DDM die Daten in die OS/400-Datenbankdatei
schreibt.

Alle Programmprodukte die ähnliches können (z.B. ASNA RPG) sind sehr schnell.

Auch mit SQL/ODBC könnt Ihr zeitliche Probleme bekommen.

Wenn die Daten erst einmal in die AS/400 sollen und kein gezielter Datenzugriff
erforderlich ist, dann könnte man per Api auch die Sätze in eine
Datenwarteschlange
schreiben, auf der AS/400 würde dann ein Serverprogramm diese Sätze lesen und in
die richtigen Dateien stellen, gegebenenfalls eine Verarbeitung anstoßen.

Ich halte nur die DDM-Lösung bzw. die API-Warteschlangenlösung für
aussichtsreich
auch wirklich GIGA-Bytes an Daten durchzuschaufeln.
---------------------------------------------
Ist zwar nicht gerade ermutigend und auch nicht unbedingt die Lösung Deines Problemes, aber ich wollte Dir diesen Beitrag nicht unterschlagen.
Gruss Reinhold

[Günther]

Hallo Lars,

wenn der Prozessor wenig braucht, könnte es an mangelndem Hauptspeicher liegen;
wieviel HSP hat die Maschine und in welchem Pool läuft der Job, bzw. wieviel HSP ist dort zugeordnet (zur Laufzeit) ?

MfG Günther

[lrmeyer]

Hallo Reinhold,

vielen Dank für Deine Mühe. Vielleicht weiß irgendjemand noch eine andere Lösung. Wie sieht es denn mit einem Releasewechsel auf V5R1 aus?

Hallo Günther,

unserer AS/400e hat 512 MB HSP. Die Java-Programme laufen im Subsystem QBATCH mit einem eingenen SHRPOOL. Dort sind 20 MB zugeordnet. Wir haben ganz bewußt nicht mehr HSP zugeordnet, damit den anderen Subsysteme nicht zuviel HSP entzogen wird. Die 20 MB scheinen aber auch ausreichend zu sein, da wir festellen konnten, das wir kaum 'Fehlseiten' (WRKSYSSTS) in diesem Subsystem haben. Ebenso konnten wir festellen, das wir zig Tausende "Seiteneinlagerungen" in diesem Subsystem haben und die Plattenauslastung bzw. Schreibleseauslastung auf den 8 Platten enorm in die Höhe schnellt.


Lars

[Günther]

Hallo Lars,

ich habe zwar keine Ahnung wieviel HSP die Java-Programme benötigen, aber 512MB insgesamt sind schon sehr dürftig, erst recht die 20MB für Java;
ich würde mal in einer schwach frequentierten Zeit dem Java-Pool z.B. 100MB spendieren und dann den 3 Stunden-Job laufen lassen, wenn er dann schneller laufen sollte, liegt die Ursache auf der Hand ...

Mfg Günther

[Sven Schneider]

Ich bin der selben Meinung wie Günther (Hauptspeicherproblem !).

Folgendes testen :
1. Systemwert QPFRADJ=3 setzen
2. Im betroffenen Subsystem den Share-Pool *BASE mit Pool-ID 1 eintragen; wichtig ist , das der betroffenene Leitwegeintrag (RTGE) der Pool-ID 1 zugeordnet ist (Subsystem QBATCH hat standardmäßig *BASE mit Pool-ID 1)
3. Poolgröße Share-Pool *BASE mit WRKSYSSTS/WRKSHRPOOL notieren
4. betroffenes (Java-Programm) ausführen u.U. mehrmals
5. Neue Poolgröße mit alter vergleichen

Hat sich der dem Pool zugeordnete Hauptspeicher signifikant verändert, hast Du ein Hauptspeicher-Problem.

Zum Thema Seitenein-/auslagerung :
Eine "Speicher"-Seite ist 4096 Byte (4K) groß.
Bei "zigtausenden" Seiteneinlagerungen kannst du ja mal ausrechnen, wann deine 20MB voll sind. --> Seitenauslagerungen mit entsprechenden Festplattenzugriffen sind die Folge.

Außerdem, so wie das aussieht versucht das Java-Programm die komplette Spooldatei im Hauptspeicher zu konvertieren. Bei kleinen Spooldateien ist das kein Problem, bei tausenden von Seiten aber ...!


Sven


[Dieser Beitrag wurde von Sven Schneider am 04. März 2002 editiert.]

[schreibr]

Von den ganzen Tips mal abgesehen habe ich gerade noch ein Redbook zum Thema Java und Performance entdeckt: http://publib-b.boulder.ibm.com/Redb...6256.html?Open

Gruss Reinhold

[lrmeyer]

Hallo zusammen,

also, zunächst einmal zur Größe der Spool-Datei, die konvertiert werden soll. Die Spool-Datei besteht aus 4 Seiten und hat eine Größe von 36 KB (Kilobyte)!!!! Das kann also alleine nicht die enormen Seiteneinlagerungen in den SHRPOOL erklären.
Damit hängt es wohl nicht zusammen.

Das Problem ist wohl eher die virtuelle Java-Maschine, die gestartet wird. Dieses Starten der JVM verursacht wohl die hohen Seiteneinlagerungen. Selbst bei einer POOL-Größe von 200 MB schaufelt die Maschine hohe Mengen an Seiten in der SHRPOOL. Auch die Plattenauslastung steigt merklich an. Das konvertieren der SPOOL-Dateien dauert auch hier geschlagene 3 Stunden. Aus mir unerfindlichen Gründen ist also Java an sich das Hauptproblem und der Verursacher.

Lars