SETOBJACC

[woodstock99]

Hallo zusammen ,

da ein Job bei uns sehr viele I/Os erzeugt wollte ich die Dateien mit den meisten I'Os in den Hauptspeicher laden um eine bessere Laufzeit zu erzielen .

Dieses habe ich mal so realisiert ..

STRSBS SBSD(xxx)
DLYJOB DLY(10) /* ALLOW TIME FOR ALLOCATION OF POOL +
MEMORY */
CLRPOOL POOL(*SHRPOOL1 5)
DLYJOB DLY(10) /* ALLOW TIME FOR CLEARING POOL */
SETOBJACC OBJ(Datei1) OBJTYPE(*FILE) +
POOL(*SHRPOOL1 5) MBRDATA(*BOTH)
SETOBJACC OBJ(Datei2) OBJTYPE(*FILE) +
POOL(*SHRPOOL1 5) MBRDATA(*BOTH)
SETOBJACC OBJ(Datei3) OBJTYPE(*FILE) +
POOL(*SHRPOOL1 5) MBRDATA(*BOTH)
SETOBJACC OBJ(Datei4) OBJTYPE(*FILE) +
POOL(*SHRPOOL1 5) MBRDATA(*BOTH)
CALL PGM(PROGRAMM) PARM('xxx')
CLRPOOL POOL(*SHRPOOL1 5)
ENDSBS SBS(xxx)


Mein Problem ist jetzt aber dass der Job eigentlich genausolange läuft wie ohne den SETOBJACC 20 sekunden Schneller bei einer LAufzeit von über einer halben STD.

Mach ich hier was falsch oder was könnte der Grund sein . Hat jemand einen Idee ?

[Fuerchau]

Das ist wie immer schwierig zu analysieren.
Neben den Daten werden ja auch die Schlüssel (LF's) benötigt.
Häufig ist es also so, dass von den Daten eher nur ein Teil benötigt wird, von den Schlüsseln wiederum mehr.
Wenn du mit dieser Methode nur 20 Sekunden für 30 Minuten rausholst liegt die Ursache eher weniger in diesen Dateien.
Dein Programm muss also noch mehr machen als nur Daten lesen und ggf. auch noch andere Dateien lesen.
Ein Problem ist häufiger auch das Schreiben wenn die Zieldatei einen spezielen FRCRATIO enthält. Hier habe ich schon bei einem CPYF Laufzeitverbesserungen von Faktor 1000 erzielt.
Das nächste Problem sind ggf. Wartezeiten auf Satzsperren. Auch wenn diese ggf. nur sehr kurz sind, so summieren sich diese.

Wenn du Performance herausholen musst muss ein sinnvolles Profiling des Programmes gemacht werden.

[woodstock99]

Kann es auch sein das er die Dateien einfach wieder aus dem Speicher wirft?
Ich beobachte dass die Grösse meines SpeicherpoolS kontinuierlich schrumpft obwohl er als *FIXED angegeben ist . Und der Job trotzdem I/Os generiert. Also zumindest laut der Anzeige des Jobs Auswahl 14 . Sollte er doch nicht mehr machen weil die fallen doch dann weg weil die Dateien im Hauptspeicher sind .. Verwirrt bin

[woodstock99]

desweiteren verstehe ich noch nicht ganz wie es sich verhält wenn ich die Dateien in einen SHRPOOL wie in meinem Beispiel lade und andere Jobs auf die Datei zugreifen .
Sehe den Vorteil bis jetzt nicht ganz .
Warum lade ich die Dateien nicht generell mit *JOB oder *Base ?

[Pikachu]

Was genau steht wo auf *FIXED?
Auch wenn die Dateien im Arbeitsspeicher liegen,
werden doch Datensätze gelesen und geschrieben, nur eben schneller.

Ich beobachte dass die Grösse meines SpeicherpoolS kontinuierlich schrumpft obwohl er als *FIXED angegeben ist . Und der Job trotzdem I/Os generiert. Also zumindest laut der Anzeige des Jobs Auswahl 14 . Sollte er doch nicht mehr machen weil die fallen doch dann weg weil die Dateien im Hauptspeicher sind .. Verwirrt bin

[woodstock99]

die Grosse des *SHRPOOL1 steht auf *fixed .
Hab den Wert auf 2 GB gestellt . Im Joblog steht auch dann schön bei der letzten Datei.
126020K of xxx brought to pool with 376340K unused.
Also noch was übrig . Sollte doch so passen oder ?
Aber die Grösse des *SHRPOOL1 wird fast sekündlich kleiner obwohl ich ein Subsystem erstellt habe , es gestartet habe und dem Subsystem den *SHRPOOL1 zugewiesen habe .

[Pikachu]

Meinst du das *FIXED im WRKSHRPOOL?
Das bezieht sich anscheinend nicht auf die Größe.
Sieh mal in der Hilfe zu den Feldern der Spalte "Definierte Größe" nach.
Wie steht der Systemwert QPFRADJ (Leistungsanpassung)?

[woodstock99]

auf 3 .. Automatic adjustment
heisst dalso das System regelt sich selber .
@Pikachu . Wie setzt man das dann richtig um ?

[Fuerchau]

An diesen Schrauben zu drehen macht nun wirklch kaum noch Sinn da die Speicherverwaltung (Paging) doch schon ganz effektiv geworden ist.
Man sollte dann doch schon lieber in die Anwendung schauen, prüfen was die da so treibt und dann dort Verbesserungen durchführen.
Wenn ich mir so per WRKACTJOB die Belastungen ansehe, so frage ich mich bei manchen Programmen wirklich:
CPU 4,4 AuxIO 1592
CPU 32,1 AuxIO 556
CPU 30,3 AuxIO 295

D.h., auch bei viel IO kann das Programm (4,4 Sek) immer noch schnell sein.
Ich hatte mal ein Problem bei einer SQL-Function die ein OPM-Programm aufruft.
Per ODBC kamen so ca. 10 Sätze/Sekunde dann auf den PC.
Nach einer Optimierung (eigenes Caching von Dateizugriffen, Konvertieren in ILE) der z.T. von dem OPM-Programm aufgerufenen Unterprogramme (z.T. Filehandler) kam ich dann auf ca. 150 Sätze/Sekunde. Das ist zwar immer noch nicht schnell aber ist nun mal der Anwendung geschuldet die in dieser SQL-Funktion nun wirklich viel rechnen muss.
Man kann also durchaus die "alten" Anwendungen noch beschleunigen wenn man sie denn analysiert.

[hel400]

.. und ganz grundsätzlich zu *FIXED, QPFRADJ und SHRPOOL:

Steht der Systemwert QPFRADJ auf >0, so werden alle SHARED Pools automatisch angepasst, also auch der hier verwendete "*SHRPOOL1".
Möchte man einen Pool definieren, der NICHT vom OS verändert wird, so muss man den selbst definieren (aber NICHt als SHR- sondern als Userpool, also beim CHGSBSD einen tatsächlichen Wert bei "Speichergröße" angeben!).

Nun zum "*FIXED": Das wird oft falsch interpretiert, hat nichts mit fixer Größe oder sonstetwas zu tun.
Anzeigen u. verändern geht in WRKSYSSTS (ASTLVL(*ADVANCED)), dann mit F11 die Anzeige umschalten.
Rechts wird dann der aktuelle Wert angezeigt - und kann auch verändert werden.
Damit kann man nun den "Expert Cache" ein- u. ausschalten.
Standard=*FIXED (also AUSgeschaltet). Stellt man auf "*CALC", so ist der Expert Cache eingeschaltet.
Damit versucht das OS, die Einlesevorgänge zu optimieren - kann besonders bei sequentieller Verarbeitung zu verbesserungen führen.
Hat aber - wie gesagt - absolut NICHTS mit Größenangaben zu tun.

Fazit:
In einen SHARED-Pool mit SETOBJACC etwas hineinzustellen, macht nicht viel Sinn, weil da sofort der PfrAdjuster (QPFRADJ) wieder hineingreift!

[Fuerchau]

Und wenn sowieso genügend Speicher für sowas zur Verfügung steht dann wird der Standardcache des OS sicherlich schon ausreichen.
Ich hatte das früher mal (V2R2) verwendet als die Platten noch sehr langsam waren und konnte damit Performance gewinnen. Allerdings hatten wir das ausschließlich auf die Indizes beschränkt.

[BenderD]

... nur so am Rande vermerkt; bei sequentieller Verarbeitung wird alles nur einmal gelesen, da bringt ein cache nix...