SMP (Symmetric Multiprocessing), QAQQINI Probleme/Erfahrungen

[lch_]

Hallo,

wir wollen SMP (symmetric multiprocessing) auf unserer AS400 (V6R1) bewusst einsetzen bzw. nutzen und führen jetzt
diverse Tests durch um dies zu bewerkstelligen (mittels CHGQRYA bzw. ändern der QAQQINI). Das Lizenzprogramm ist installiert und aktiviert. Prinzipiell wollen wir den Indexaufbau
parallelisieren wenn große Datenmengen zB. mittels CPYF oder ähnliche Methoden umkopiert werden.

Hier gibts ein Dokument dazu: Process your DB2 for i indexes in parallel

Ein Test sieht zB. wie folgt aus:

1) Anlegen einer leeren physischen Datei mit ca. 10 logischen Dateien in einer Bibliothek (MYLIB2)

2) Anschließend submitten wir einen Job der ein einfaches CL aufruft welches folgende Befehle ausführt:

       
CHGQRYA  DEGREE(*OPTIMIZE) /* Nutzung von SMP (auch *MAX möglich) */

CPYF FROMFILE(MYLIB1/TST020XX) +
        TOFILE(MYLIB2/TST020XX) +
            MBROPT(*REPLACE) +
            CRTFILE(*NO)

Um die "Verbesserungen" vergleichen zu können haben wir das CPYF ohne den vorherigen CHGQRYA Befehl im CL ausgeführt. Die Läufe ohne diesen Befehl bzw. ohne die optimierung waren leider durchwegs schneller, dies konnten wir jetzt nicht wirklich nachvollziehenwieso das passiert. Jetzt haben wir auch schon etwas recherchiert und nachgeforscht und haben gehört das der CPYF Befehl die SMP Einstellungen einfach ignoriert bzw. nicht unterstützt.

Meine Frage: Setzt ihr SMP ein, was sind eure Erfahrungen und wie verwendet ihr es?

Vielen Dank schon mal,
lg christoph

[Chris.jan]

Vielleicht ist die Festplatte einfach nur nicht schnell genug. Zuviele IOs oder eine zu hohe Disk Utilisation kann ja schließlich nicht von einem zweiten CPU aufgefangen werden.

[camouflage]

So wie ich das verstanden habe, bringt SMP vor allem im Zusammenhang mit SQL, Open Query, Query, Index Creation und Maintenance, sowie CPYFRMIMPF und RGZPFM etwas.

>> HLL native I/O is not enabled.

(Schulungsunterlagen SMP von IBM)

Da müsstest Du die Versuche schon mit SQL machen.

[Chris.jan]

Da bieten sich speziell Joins an. Und wenn du vorher noch den debugger startest, dann sieht man schln im Joblog was die Query Optimization im Hintergrund macht.

[Pikachu]

Prinzipiell wollen wir den Indexaufbau parallelisieren wenn große Datenmengen zB. mittels CPYF oder ähnliche Methoden umkopiert werden.

Wenn ihr die Zugriffspfade löscht und anschließend wieder anlegt (sofern das bei euren Abläufen geht), ist das vermutlich schneller als jeden Datensatz von der Datenbank einzeln in die Zugriffspfade einsortieren zu lassen.

[Chris.jan]

Genau so:
CHGPF MAINT(*DLY) ausschalten
CPYF FROMRCD(1) sequentiell kopieren
CHGPF MAINT(*IMMED) einschalten

Ist meiner Erfahrung nach die schnellste Methode.

[Fuerchau]

Und wenn man noch ein wenig den Link nachliest, dann ist z.B. REUSEDLT(*YES) beim CPYF schädlich, da dann SMP auch wegfällt. REUSEDLT(*YES) ist bei SQL-Tables im Übrigen per Default eingestellt.

Um also den CPYF zu beschleunigen sollte man halt (wie oben beschrieben)
- alle LF's und die PF die Maintanance abschalten
- REUSEDLT(*NO) setzen
- dann erst kopieren
- Maintanance und REUSEDLT(*YES) wieder setzen

Da SMP im Wesentlich auf Index-Aufbau zielt bringt das bei Select's dann nichts, wenn vorhandene Indizes verwendet werden können.
Ein temporärer Index sollte sowieso vermieden werden, da dies auch bei SMP die Abfrage verlangsamt.

Was SMP dann noch wirklich bringt weiß ich auch nicht, da die Parallelität eher durch viele Abfragen verschiedener Job's gewährleistet ist als durch eine einzelne Abfrage eines einzelnen Job's.

M.a.W.: nur eine Geldmaschine für die IBM.

[BenderD]

... dem kann ich nur vehement widersprechen! Bei Bulk SQL Skripten ist das in vielen Fällen der Bringer, wenn man die entsprechenden Hardware Ressourcen hat!

D*B

M.a.W.: nur eine Geldmaschine für die IBM.

[Fuerchau]

Aber Bulk-SQL's sind in einer Anwendung doch eher die Ausnahme.
Bei ein paar hundert oder tausend Insert's merkt man das auf der AS/400 fast gar nicht.
Im Mehruser/-job-Betrieb kann ich durchaus ohne SMP 20.000 Insert's / Sekunde oder mehr erreichen (Beispiel CPYF).

[BenderD]

... ich rede da von Tables mit 1000 Mio Sätzen, dynamisch generierten SQL Zugriffen (Stichwort DWH) und etlichen Millionen Transaktionen, die man unterbekommen will und Batchjobs, die in solchen Umgebungen mit minimalster Ressourenbelastung stundenlang vor sich hindümpeln; da kann die Investition in das Parallel Database Feature eine für den Kunden außerordentlich lohnende Maßnahme sein.

D*B

Aber Bulk-SQL's sind in einer Anwendung doch eher die Ausnahme.
Bei ein paar hundert oder tausend Insert's merkt man das auf der AS/400 fast gar nicht.
Im Mehruser/-job-Betrieb kann ich durchaus ohne SMP 20.000 Insert's / Sekunde oder mehr erreichen (Beispiel CPYF).

[lch_]

Hallo,

danke schon mal für die ganzen Rückmeldungen. Bei meinen derzeitigen Tests handelt es sich noch um PF/LF Files, also keine SQL Tables und REUSEDLT ist auf *NO gestellt. Ich werde mal diesen Ansatz verfolgen:

CHGPF MAINT(*DLY) ausschalten
CPYF FROMRCD(1) sequentiell kopieren
CHGPF MAINT(*IMMED) einschalten

Anschließend baue ich mir noch ein Testszenario mit SQL Tables und werde testen ob das SMP hier dann greift und was es bringt.

Danke schon mal, lg Christoph

[BenderD]

... das CPYF scenario ist für diese Art Tests ungeeignet. Ein Datenbankfeature kann man nicht mit einer Betriebssystem Operation evaluieren (CPYF mit Replace braucht die Tabelle exclusiv, Änderung des maint Parameters ebenfalls).