[NEWSboard IBMi Forum]
Seite 2 von 2 Erste 1 2
  1. #13
    Registriert seit
    Aug 2003
    Beiträge
    1.425
    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)

  2. #14
    Registriert seit
    Nov 2018
    Beiträge
    31
    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

  3. #15
    Registriert seit
    Feb 2001
    Beiträge
    18.009
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  4. #16
    Registriert seit
    Mar 2002
    Beiträge
    4.807
    Zitat Zitat von franz77 Beitrag anzeigen
    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.
    ... der IBM Support war auch schon mal besser.

    Was da so passiert, lässt sich leicht nachvollziehen:

    Als erstes macht man das unter debug und sieht ins Joblog, wo man dann diagnostics der Query engine findet. Dort sieht man, dass - welch Überraschung - der insert erst mal einen open macht; am billigsten ist da ein öffnen nach Eingangsfolge (womit der visuelle Explain schon aus der Kurve fliegt - die Tools waren auch schon mal besser).

    Als nächstes macht man ein STRDBMON TYPE(*DETAIL) und lässt erneut rattern. Dann sieht man sich das ganze an (mit SELECT QQTIME, QQSTIM, QQETIM, QQ1000 FROM ...)
    da sieht man dann, dass erst mal ein Connect gemacht wird, dann kommt eine Stafette von Einträgen, die auch davon abhängt, was man da genau macht (static SQL, dynamic SQL, prepare once run multiple...). Die Zeit für den insert ist in dem Eintrag für den insert in Anfang Ende Timestamp komplett, inklusive prepare, dargestellt.

    300 Millisekunden sind keineswegs in Ordnung, da ist was krumm - ob es sich rentiert danach zu suchen, hängt davon ab, ob es stört. Für elementare DB Operationen sind Zeiten von max. 1 Millisekunde typisch, auf schnellen Maschinen auch deutlich besser, auf schwächlichen Maschinen auch wenige Millisekunden. Auf einer meiner Spielzeugmaschinen waren es hier knapp 6 Millisekunden beim Erstaufruf, knapp 4 bei Folgeaufrufen (caching lässt grüßen)

    Rekord Löffel ist für elementare Operationen immer schneller, egal wovon das IBM Marketing gerade träumen macht, ändern könnte man das, indem man den RLA langsamer macht.
    Für komplexe Transaktionen hat SQL mehr Möglichkeiten zu cachen und kann seine Nachteile auch überkompensieren; in der Programmierer Performance ist SQL immer schneller, wenn vor dem Bildschirm ein Profi sitzt.

    D*B

    PS: SETOBJACC reduziert natürlich den verfügbaren Speicher und verdrängt erst mal anderes aus dem Speicher. Das reinpagen größerer Programme (auch der SQL runtime) ist auf einer AS/400 kein Renner (single level storage lässt grüßen). Knapper Hauptspeicher erklärt oft zähe Erstaufrufe.
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  5. #17
    Registriert seit
    Nov 2018
    Beiträge
    31
    Zitat Zitat von Fuerchau Beitrag anzeigen
    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

  6. #18
    Registriert seit
    Feb 2001
    Beiträge
    18.009
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  7. #19
    Registriert seit
    Nov 2018
    Beiträge
    31
    Zitat Zitat von Fuerchau Beitrag anzeigen
    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

  8. #20
    Registriert seit
    Mar 2002
    Beiträge
    4.807
    Zitat Zitat von franz77 Beitrag anzeigen
    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
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  9. #21
    Registriert seit
    Nov 2018
    Beiträge
    31
    So. neue Lage:

    Bei dem ganzen Hin- und Hertesten der letzten Tage ist natürlich eines passert. Ich habe unabsichtlich in einer Testlib 10 Indices auf die Produktivtabelle hinterlassen, welche natürlich nicht mir SETOBJACC im Speicher waren und auch sonst komplett sinnlose spalten indiziert hatten.

    Hab die Dinger nun weggeworfen und siehe da: erstes insert 120ms, jedes weitere unter 4ms.

    Sehr unangenehm...

    Ich werde das weiter verfolgen.

    LG,
    Franz

  10. #22
    Registriert seit
    Feb 2001
    Beiträge
    18.009
    Da kann man mal wieder die Blödheit des Optimizers erkennen (tut mir leid, aber das ist halt so), dass er nicht registriert, dass es sich
    a) um einen Insert handelt und
    b) in den Values() kein Select
    angefragt wird. In diesem Fall ist eine Indexanalyse natürlich Humbug.
    Unabhängig von deinen nun gelöschten Indizes kann es ja durchaus Sinn gehabt haben, diese Indizes zu erstellen.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  11. #23
    Registriert seit
    Mar 2002
    Beiträge
    4.807
    ... 10 Indexe wollen zur maintenance beim Insert erst mal alle seitenweise reingepaged werden, das dauert schon. Der Query Optimizer hat hier bei static SQL erst mal nicht viel zu tun.
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

Ähnliche Themen

  1. Insert mit SQL Prozedur liefert Resultset mittels Final Table
    Von Gutmann im Forum NEWSboard Programmierung
    Antworten: 11
    Letzter Beitrag: 06-09-17, 07:55
  2. RPG SQL Insert VALUES(Datenstruktur)
    Von ASFOURI im Forum NEWSboard Programmierung
    Antworten: 7
    Letzter Beitrag: 02-11-16, 11:34
  3. VALUES Check auf Inputfeld ignoriert
    Von camouflage im Forum NEWSboard Programmierung
    Antworten: 4
    Letzter Beitrag: 18-08-15, 14:10
  4. %SCAN im CL Programm
    Von Etherion im Forum NEWSboard Programmierung
    Antworten: 10
    Letzter Beitrag: 06-11-13, 18:24
  5. SCAN bei ILE RPG ???
    Von HoScHiE im Forum IBM i Hauptforum
    Antworten: 3
    Letzter Beitrag: 06-09-01, 16:37

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •