insert mit values macht immer table scan

[Fuerchau]

Seit wann ist Open/Close inhaltsabhängig;-)?

[franz77]

Ich habe das gestern und heute mit dem IBM Support diskutiert mit folgender Conclusio.

Beim Insert wird tatsächlich sowas ähnliches wie ein Tables-Scan gemacht. Das Visual-Explain zeigt dann halt Table-Scan an.

Die 300ms sind nicht extrem ungewöhnlich, beim ersten Ausführen. Das Problem ist dem IBM Support schon öfter mal untergekommen und wurde auch zutodeanalysiert.

Mit dem Outcome, dass es vorallem auf Systemen auftritt, die sich den ganzen Tag langweilen.

Wir haben sehr viel debuggt und auffällig ist schon, dass das insert mit strsql wesentlich schneller geht als über embedded sql (2x). Wirklichen Grund haben wir dafür aber nicht gefunden. Mein Sourcecode ist supersimpel.

Was interessant is ist, dass das Einfügen in die selbe Tabelle mit Native - IO (RPG Write) beim ersten Mal immer unter 20ms dauert, also über 10x mal so schnell ist. Meistens sogar unter 10ms, also 30x so schnell.

Deckt sich das mit euren Erfahrungen?

[andreaspr@aon.at]

Könnte durchaus sein, dass mit Native IO es etwas schneller geht.
Das mit dem Testen ist jedoch so eine Sache ...
Hast du den Native IO Test direkt nach dem SQL Test gemacht?
Wenn die Tabelle einmal im RAM ist geht's grundsätzlich schon mal schneller und das ist auch das Problem bei Systemen die sich Langweilen, im Gegensatz zu System die aktiv sind.
Dort sind Tabellen bzw. Objekte die öfters verwendet werden auch im RAM und dadurch schneller zugreifbar.
Dann wäre auch noch die Frage wie die Zeitmessung bei Native IO ausgesehen hat? Vor dem Programm start oder im Programm? Wenn im Programm, hast du mit USROPN gearbeitet und den Startzeitpunkt vor dem OPEN gesetzt usw.

lg Andreas

[franz77]

Die Tests werden immer mit einem neuen Job ausgeführt. Ich melde mich im Terminal ab, schliesse den Terminal-Client und mache eine neue Session auf.

Bei SQL reicht das damit das erste insert wieder langsam ist.

Ich habe den rpg-code für die Native-Variante unten angehängt (Davor findest Du die Ausgabe). In dem Beispiel ist die Tabelle eine andere als oben in meinem Post, der Effekt ist aber genau der gleiche. Bei dieser Tabelle im Code unten dauer das insert mit embedded sql beim ersten mal immer ca 240ms. Wie man sehen kann brauch der RPG-Code ca 22ms.

LG,
Franz




----------------------------------------------

DSPLY Start
DSPLY 2018-12-20-17.34.21.269
DSPLY 2018-12-20-17.34.21.291
DSPLY End

--------------------------------------------

**free
ctl-opt option(*DEBUGIO: *SRCSTMT) ccsid(*char:*jobrun) actgrp(*new) datfmt(*iso);


dcl-f xxzb extfile(*extdesc) extdesc('TESTLIB3/TBZB') USAGE(*INPUT: *OUTPUT);


dcl-s ts char(30) dim(10);

dcl-s inp01 char(1);

dsply 'Start' '*EXT' inp01;

ts(1) = %char(%timestamp(*SYS : 3));

zbid = 100002;
zbdatum = %date();
pvid =1;
maid = 1;
zbstatus = 0;


write tbzb;
ts(2) = %char(%timestamp(*SYS : 3));

dsply ts(1);
dsply ts(2);

dsply 'End' '*EXT' inp01;
return;

[Fuerchau]

Das ist mir schon klar.
Aber:
Hast du dir mal die Mühe gemacht einen TRCJOB durchzuführen?
Da kannst du sehr schön verfolgen, was da so alles aufgerufen wird.

Bei RLA werden direkt die "hart verdrahteten" CALL-Aufrufe der QDB-Routinen, QDBGET, QDBPUT, verwendet.
Bei SQL startest du mit einem QSQxxx-Aufruf (Spool-Liste), der noch verschiedene weitere Routinen durchläuft bevor er endlich QDBPUT erreicht.
Vergleiche diese Aufrufe mit dem 1. SQL-Insert und dem 2. SQL-Insert.
Dann weißt du, wo die Zeiten verbraten werden.

Im Vergleich zu RLA wird SQL nie vergleichbare Geschwindigkeiten erreichen können, da hier ein gigantischer Overhead betrieben werden muss.
Zumal hier noch interne variabel definierte Felder gegenüber statischen Feldern in RPG gegenüber stehen. Alleine schon die Neudefinitionen der Hostvariablen ist eigentlich unnötig.
Allerdings wird sich wohl kaum jemals noch jemand hinsetzen und einen komplexen SQL mit Joins, derived Tables, rekursive CTE's sowie Gruppierung, Filter, Aggregierung in RLA umzusetzen.

[andreaspr@aon.at]

Genau das meinte ich, probiere mal die DCL-F Anweisung mit usropn zu definieren.
So, kann es nämlich sein, dass der Pfad zur Tabelle (ODP) schon beim Starten des Programms getätigt wird, noch bevor du den 1. Timestamp speicherst.
Also:
1. Timestamp speichern
2. open tbzb
3. write tbzb
(4. close tbzb)

[franz77]

Das ist natürlich ein valider Punkt

ich hab das gemacht und die Werte sind so:

open + write dauert 40-50ms. das Open selbst dauert dabei aber nur ein paar ms.

Um das ganze nochmal einzuordnen: Die 300ms stören mich so, weil ich eigenlich die ganze Produktiv-DB mit setobjacc im RAM habe (Nicht die Tabelle mit der wir hier die Tests gemacht haben!!), das alles also extrem flott gehen soll. Da fällt das auf wenn auf einmal ein Request reproduzierbar länger dauert. Es dürfte, wie schon vorher besprochen eben die SQL-Engine sein, die da alles möglich optimiert, was eigentlich in diesem Case sinnlos ist.

Ich werde meine Applikation beim insert und Delete jetzt mal for Fun auf RLA umbauen und schauen wie das dann so tut.

LG,
Franz

[Fuerchau]

Mittels SETOBJACC, das ist meine Erfahrung, verschlechterst du das Pagingverhalten.
Du nimmst nämlich ordentlich Speicher weg, der dem Paging dann nicht mehr zur Verfügung stellst.
Benutzt du da keinen eigenen Pool, bringt das noch weniger, da die geladenen Objekte per Paging wieder verdrängt werden. Hinzu kommt, dass SETOBJACC das gesamte Objekt in den Speicher lädt.
Außerdem ist der Zugriff auf die Tabellen nicht das Problem, sondern der Zugriff über Indizes.
Fehlende Indizes sind dazu noch störender und VARLEN/Varying Felder erfodern u.U. doppelte Zugriffe.

Die Frage ist eben, welche Objekte genau in den RAM geladen werden.

Ich nehme mal nur eine einfache Tabelle, in der Informationen per Datum über die letzten 20 Jahre gespeichert sind.
Wie ist die Verteilung der Zugriffe hier?
Sind da nicht i.d.R. 99% der Zugriffe auf 5% der Daten?
Und nehme ich nun kleinere Tabellen (incl. Indizes!) auf die sehr häufig zugegriffen werden, so landen diese langfristig sowieso fast statisch in den Speicher.

[franz77]

Mittels SETOBJACC, das ist meine Erfahrung, verschlechterst du das Pagingverhalten.
Du nimmst nämlich ordentlich Speicher weg, der dem Paging dann nicht mehr zur Verfügung stellst.
Benutzt du da keinen eigenen Pool, bringt das noch weniger, da die geladenen Objekte per Paging wieder verdrängt werden. Hinzu kommt, dass SETOBJACC das gesamte Objekt in den Speicher lädt.

Speicher haben wir genug. 32GB RAM und es läuft fast nix. Für das SETOBJACC hab ich einen eigenen Pool gemacht *SHRPOOL1. Dieser wird exclusiv für SETOBJACC verwendet und hat eine fixe Größe (10%min, 10%max)


@BenderD: Wenn mehrere User gleichzeitig angemeldet sind und die AS400 alles schon bei der Hand hat, dann gehts e flott. Die hohe Zeit beim Insert ist nur, wenn niemand andere angemeldet ist. DMBOM usw habe wir alles gemacht. Die Maschine ist mit den 2 x 10k Disks, 1 Core und dem Controller ohne Write-Cache nicht soo schnell. Journaling läuft auch.

LG

[Fuerchau]

Also 32GB sind da nicht allzu viel, ich kenne da schon andere Maschinen (256GB).
Zumal, wenn du Tabellen mit mehreren GB's hast.
Lass mal den SETOBJACC weg und schlage den Pool wieder dem Speicher zu, du wirst sogut wie keinen Unterschied feststellen.
Zumal, wenn das System sowieso daher dümpelt.

[franz77]

Also 32GB sind da nicht allzu viel, ich kenne da schon andere Maschinen (256GB).
Zumal, wenn du Tabellen mit mehreren GB's hast.
Lass mal den SETOBJACC weg und schlage den Pool wieder dem Speicher zu, du wirst sogut wie keinen Unterschied feststellen.
Zumal, wenn das System sowieso daher dümpelt.

;-) Irgendwie sind wir nicht der Typische AS400 Kunde

Die Tabellen die ich in unsere DB reinlade haben insgesamt ca 1 GB ;-)
Da es eine P05 Maschine ist sind 64GB sowieso das Maximum (32GB habe wir gekauft).

Aber ich gebe Dir recht. Der Unterschied zwischen SETOBJACC und ohne ist, wenn das System von mehrerten Leuten gleichzeitig benutzt wird nicht allzu groß. Viel mehr merkt man das manchmal aufgedreht DBMON.

Das SETOBJACC verwende ich, um den Festplatteneinfluss auf meinen Test so gut wie möglich zu reduzieren. Sollte ich mal mehr Speicher brauchen, dann werd ichs aber e wieder wegnehmen.

Sonst läuft noch der *HTTP *ADMIN und das wars - wenn ich ihn nicht gerade sowieso abdrehe.

Vielleicht kommt nächstes Jahr noch der Domino hinzu.

Da wir erst seit ca 6 Monaten in dem AS400 Thema unterwegs sind versuche ich alle Auffälligkeiten zu ergründen. Das hat immerhin schon zu 2 PTFs für den NetServer geführt die auf meine Tests zurückgehen ;-)

LG,
Franz

[BenderD]

Speicher haben wir genug. 32GB RAM und es läuft fast nix. Für das SETOBJACC hab ich einen eigenen Pool gemacht *SHRPOOL1. Dieser wird exclusiv für SETOBJACC verwendet und hat eine fixe Größe (10%min, 10%max)


@BenderD: Wenn mehrere User gleichzeitig angemeldet sind und die AS400 alles schon bei der Hand hat, dann gehts e flott. Die hohe Zeit beim Insert ist nur, wenn niemand andere angemeldet ist. DMBOM usw habe wir alles gemacht. Die Maschine ist mit den 2 x 10k Disks, 1 Core und dem Controller ohne Write-Cache nicht soo schnell. Journaling läuft auch.

LG

... die 10% beim SETOBJACC machen nix kaputt und retten auch nix.
Wenn fast nix und alle abgemeldet bedeutet, dass da ein Batchjob dümpelt, der z.B.: eine größere Datei sequentiell verarbeitet, dann verdrängt der alles andere aus dem Hauptspeicher (ohne dass es diesem was bringt) und dann paged sich der interaktive Job erst mal rein, was ohne weiteres 300 Millisekunden (oder mehr) verbruzzeln kann.
Für solche Konstellationen ist controlling SBS QBATCH absolut ungeeignet. Mit QCTL lässt sich der Batchjob in einem limitierten Pool einsperren (QPFRADJ abschalten!!!) und die interaktiven Job behalten ihre dringend benötigte Runtime im Speicher.

D*B