AS400ConnectionPool

[max40]

Moin,
ich habe das Problem, dass ein Java-Programm auf der AS400 recht zügig arbeitet und irgendwann nichts mehr zu verarbeiten hat. Nach einer Zeit soll die Anwendung wieder was machen (wird über Dtaq angestoßen), ist aber dann am Anfang sehr lahm (obwohl es noch läuft, also keine Startinitialisierungen). Statt 1 Sekunde braucht der Vorgang 15 Sekunden (nachfolgende gehen wieder zügig). Leider ist dieses auf einer anderen Maschiene (wo ich auf die schnelle ein paar Logs raushauen könnte) nicht zu beobachten.

Kann sowas mit dem AS400ConnectionPool zusammenhängen?
Wenn ja, welche (und wo überall) Einstellungsmöglichkeiten gibt es, damit man dies abstellen kann?

Habt ihr ggf. andere Ideen?

Danke + Gruß
Max

[BenderD]

... hört sich nach Workmanagement Problem an. Eigenes´Subsystem mit reserviertem Speicher sollte das heilen. Außerdem würde ich einen anderen Connection Pool empfehlen, der Toolbox Krumschel taugt nix!

D*B

[Fuerchau]

Leider kann man die QZDASOINIT-Jobs nicht so einfach umhängen und sollte man auch nicht tun.
Die laufen normalerweise schon im Subsystem QUSRWRK.
Allerdings läuft der im Pool *BASE, der sich sowieso den Hauptspeicher nimmt wie er ihn braucht.
Die Frage ist halt, wie die AS/400 so ausgelastet ist, einen inaktiven Job wieder einzulagern geht eigentlich relativ schnell.

Der Connectionpool hat damit eigentlich nichts zu tun, da die inaktive Verbindung den QZDA-Job ja immer noch belegt.

Das Problem müsste da an einer anderen Stelle liegen.
Ist denn der 1. Start der Verbindung auch so langsam?
Der eigentlich Connect dauert meist weniger als 1 Sekunde.

Mal den ConnectionPool wirklich abschalten damit der QZDA-Job frei wird.
Die AS/400 führt nämlich quasi einen eigenen Pool mit diesen Job's so dass ein Wiederverbinden zügig klappt.

[BenderD]

... das Problem sind nicht (in Worten: nicht!!!) die QZDA Jobs, sondern die JVM wird wohl aus dem Hauptspeicher verdrängt...

D*B

[Fuerchau]

Da könnte man doch sicherlich was machen.
Beim receive DTAQ einfach mit Timeout warten.
Wenn Timeout dann halt nichts tun und wieder auf receive gehen.
Die JVM müsste dann (mit welchen Nachteilen auch immer) aktiv bleiben.

[BenderD]

... single level store! RCVDTAQ ist auch mit Timeout ein Long wait. Und dein Kreischen fahren verhindert nicht wirklich, dass große Teile der JVM rausgepaged werden und das Seitenweise reinpagen ist auch das, was die Ladezeit der JVM so grottenschlecht macht.

[max40]

Außerdem würde ich einen anderen Connection Pool empfehlen

Was ist die Alternative? Oder selber machen?

Einige Infos konnte ich noch ermitteln:

Das holen von Connections hält sich im ms Bereich, also kann man dieses ausschließen.

Was mir auffällt, dass sonst die Programme mit einer 64bit JVM laufen. Liegt es vielleicht daran?
Die AS400 hat wohl Arbeitsspeicher im 3-Stelligen Bereich
Momentan bin ich noch ratlos iund weiß nicht wo ich anfangen soll zu suchen.

Hier mal die Properties, vielleicht könnt ihr was dazu sagen?!

java.vendor = IBM Corporation
java.security.debug = false
sun.management.compiler = IBM Classic JIT
PATH = /usr/bin:.:/QOpenSys/usr/bin:/QOpenSys/bin:
os.name = OS/400
sun.boot.class.path = /QIBM/ProdData/Java400/jdk6/jdkawt.jar:/QIBM/ProdData/Java400/jdk6/lib/jdkptf16.zip:/QIBM/ProdData/Java400/jdk6/lib/ibmjssefw.jar:/QIBM/ProdData/Java400/jdk6/lib/ibmjsseprovider2.jar:/QIBM/ProdData/Java400/jdk6/lib/IBMi5OSJSSE.jar:/QIBM/ProdData/Java400/jdk6/lib/jsse.jar:/QIBM/ProdData/Java400/jdk6/lib/ibmjcefw.jar:/QIBM/ProdData/Java400/jdk6/lib/ibmjaas.jar:/QIBM/ProdData/Java400/jdk6/lib/ibmcertpathfw.jar:/QIBM/ProdData/Java400/jdk6/lib/ibmcertpathprovider.jar:/QIBM/ProdData/Java400/jdk6/lib/ibmpkcs.jar:/QIBM/ProdData/Java400/jdk6/lib/CmpCrmf.jar:/QIBM/ProdData/Java400/jdk6/lib/ibmjgssfw.jar:/QIBM/ProdData/Java400/jdk6/lib/ibmjgssprovider.jar:/QIBM/ProdData/Java400/jdk6/lib/ibmsaslfw.jar:/QIBM/ProdData/Java400/jdk6/lib/ibmsaslprovider.jar:/QIBM/ProdData/Java400/jdk6/lib/charsets.jar:/QIBM/ProdData/Java400/jdk6/lib/resources.jar:/QIBM/ProdData/Java400/jdk6/lib/rt.jar:/QIBM/ProdData/OS/Java/jdk/lib/IBMmisc.jar:/QIBM/ProdData/Java400/
os400.defineClass.optLevel = 0
java.vm.specification.vendor = Sun Microsystems Inc.
os400.class.path.security.check = 20
os400.define.class.cache.file = /QIBM/ProdData/Java400/QDefineClassCache.jar
java.runtime.version = 1.6.0_11-b03
javax.activation.debug = false
java.compiler = jitc
os400.debug = 0
user.language = de
sun.boot.library.path = /QIBM/Proddata/Java400/jdk6/PASE32/lib/headless/:/QIBM/Proddata/Java400/jdk6/PASE32/lib/:/QSYS.LIB/QSYS2.LIB:/QSYS.LIB/QJAVA.LIB:/QSYS.LIB:/QSYS.LIB/QHLPSYS.LIB:/QSYS.LIB/QUSRSYS.LIB
java.use.policy = true
mail.debug = false
java.version = 1.6.0
os400.class.path.tools = 0
user.timezone = Europe/Zurich
java.net.preferIPv4Stack = false
sun.cpu.isalist = PowerPC
file.encoding.pkg = sun.io
file.separator = /
java.specification.name = Java Platform API Specification
os400.create.type = interpret
java.class.version = 50.0
user.country = DE
os400.verify.checks.disable = 65535
java.home = /QIBM/ProdData/Java400/jdk6
java.vm.info = build JDK-1.6, native threads, jitc
os.version = V6R1M0
os400.gc.heap.size.max = 2097152
path.separator = :
java.vm.version = 1.6
-Djava.version = 1.6
java.util.prefs.PreferencesFactory = java.util.prefs.FileSystemPreferencesFactory
sun.io.unicode.encoding = UnicodeBig
os400.vm.inputargs = -Djava.version=1.6 -Djava.awt.headless=true -Xmx2048M -Xms0512M
awt.toolkit = sun.awt.motif.MToolkit
java.specification.vendor = Sun Microsystems Inc.
java.library.path = /QSYS.LIB/QSHELL.LIB:/QSYS.LIB/QGPL.LIB:/QSYS.LIB/QTEMP.LIB::
java.vendor.url = IBM - United States
java.vm.vendor = IBM Corporation
java.runtime.name = Java(TM) 2 Runtime Environment, Standard Edition
os400.run.mode = jitc
java.class.path = ./lib/ext/start.jar:
os400.optimization = 0
java.vm.specification.name = Java Virtual Machine Specification
java.vm.specification.version = 1.0
sun.cpu.endian = big
java.awt.headless = true
java.net.preferIPv6Addresses = false
java.io.tmpdir = /tmp/
os400.job.file.encoding = Cp273
java.vendor.url.bug = IBM - United States
os.arch = PowerPC
java.awt.graphicsenv = sun.awt.X11GraphicsEnvironment
java.ext.dirs = /QIBM/ProdData/Java400/jdk6/lib/ext:/QIBM/UserData/Java400/ext
line.separator =
java.vm.name = Classic VM
java.policy = /QIBM/ProdData/Java400/jdk6/lib/security/java.policy
user.region = DE
file.encoding = ISO8859_1
os400.gc.heap.size.init = 524288
os400.stdin.allowed = 1
java.specification.version = 1.6
os400.jdk.provider = sun

[BenderD]

... die 32 Bit ist schneller als die 64 Bit, die ohnehin Auslaufmodell ist, Classic VM. wie eure properties ausweisen ist 64 Bit.

Connection Pool: zum Beispiel c3p0, selber schreiben tut man das nicht.

Beides ist für euer Problem sekundär. Das Problem ist, dass die "schlafende" JVM aus dem Hauptspeicher auf Platte ausgelagert wird und bei Reaktivierung die Maschine nicht aus dem Quark kommt.

Abhilfe: neues Subsystem einrichten, mit reserviertem Speicherpool in Größe des Java Jobs und selbigen über eine zugewiesene JobQ submitten, dann ist der immer gleichschnell, egal wielange da niemand was von wollte.

D*B

[max40]

Okay, werden wir mal testen. Die java jobs (ca 4) laufen schon im eigenen subsystem. Daneben noch einige rpg programme die die dtaq füttern. Reicht zum testen wenn man dem subsystem 4gb zuordnet, wovon 2gb für java nötig sind? Oder besser wirklich java für sich laufen lassen?
Danke + Gruss
Max

[BenderD]

... wenn das gekoppelte Workload ist, kann das in einem Subsystem laufen. Speicherbedarf - muss man mal sehen, ob man das aus den Jobinformationen ermitteln kann, ansonsten: Versuch macht kluch.

D*B