[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    Nov 2018
    Beiträge
    35

    Tracing oder Debugging von File Operationen

    Hi!

    Gibt es eine Möglichkeite File Operationen in RPG genau zu tracen. Mich interessiert zum Beispiel bei einem Write in eine Tabelle, was er genau macht und was dabei wie lange dauert.
    Genauso bei Chain oder Read. Also zB, ob er auf die Disk muss oder im Speicher ließt, ob er einen Index angreift,...

    Mir gehts nur um Record-Level IO (chain, read write update), also nicht SQL.

    Wenn ich STRDBG verwende, dann kann man das bei Embedded SQL relativ genau aufgeschlüsselt sehen. Sowas änliches hätte ich geren für Nativ IO.

    Der Performance-Monitor ist für meinen Einsatzzweck viel zu grob.

    BG,
    Franz

  2. #2
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Da ist mir persönlich nichts bekannt.
    Das Problem ist, dass die eigentlichen Operationen durchaus asynchron von den DB-Jobs, IO-Controllern usw. erledigt werden (Write-Cache).

    Wofür benötigst du das denn?

    Performancemessungen kann man sowieso nicht mit einzelnen IO's machen sondern nur mit 1000den Operationen um dann eine Durchschnittszeit zu ermitteln. Je nach Tageszeit (also der verfügbaren Ressourcen) können die Ergebnisse da sehr unterschiedlich sein.

    Du kannst nur einen TRCJOB machen, der die Aufrufe und Dauer der Call's aufzeichnet um vielleicht eine Aussage zu treffen.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  3. #3
    Registriert seit
    Dec 2014
    Beiträge
    310
    .. und noch etwas als Ergänzung:

    1) Ob er auf Disk oder im Speicher liest, kann man in den Debugnachrichten bei SLQs auch nicht sehen.
    2) Ob er einen Index angreift - diese Frage stellt sich ja gar nicht, weil beim Chain etc.. muss man die LF sowieso genau angeben

  4. #4
    Registriert seit
    Nov 2018
    Beiträge
    35
    Zur Info. Wir haben keinen Write-Cache

    Das Thema ist eigentlich immer weider das selbe. Ich würde gerne ergründen, wieso manche Schriebvorgänge manachmal 30ms und dann wieder 170ms brauchen, obwohl das System nie unter Last steht und ich der einzige User am System bin. Es laufen auch keine Batchjobs.

    Es betrifft eigentlich immer den ersten Schreibvorgang auf ein bestimmtes File im Job. Dieser ist von der Performance inkonsistent. Danach gehts e im Bereich von <10ms

    Die PFILEs sind alle mit SETOBJACC zuverlässig im Speicher geladen (Was ich da mache wurde auch von der IBM als richtig bestätigt, die Files werden also nicht irgendwann rausgepaged).

    Bisher war das Thema immer irgendwo bei den paar Indices auf die Tabelle angesiedelt. Aber auch diese sind mit SETOBJACC im RAM.

    Die Tabelle um dies geht hat ca 12000 Einträge und 2 Indices (einer mit allen Spalten der Tabelle)

    In wirklichkeit is es das gleiche Thema wie das: http://www.newsolutions.de/forum-sys...mer-table-scan

    Nur diesmal hab ich alles mit Native-IO gemacht und nicht mit SQL. Performance ist extrem viel besser, aber immer noch inkonsistent.

  5. #5
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Um eine nahezu konsistente Antwortzeit zu erfahren musst du wohl sämtliche Subsysteme und Dienste heruterfahren um wirklich ganz alleine auf der Kiste zu sein.
    Und selbst dann wird es wohl nicht so sein.

    Wie bereits gesagt, du schraubst da sicher an der faschen Ecke, denn man darf nicht den erstmaligen Zugriff betrachten.

    "Wir haben keinen Writecache" <= wie sicher bist du dir da?

    Den Cache einer Datei wirst du nur mit FRCRATIO(1) abschalten können. Dann ist garantiert, dass jeder Satz sofort bis zur Disk geroutet wird bevor es weitergeht.
    Ein CPYF kann dann schon mal von 20/30.000 Sätzen/Sekunde (oder mehr) auf 100/Sekunde oder sogar weniger runtergehen. Das wirst du nicht wirklich wollen.

    Was für einen Zweck hat deine ganze Analyse?

    Um moderne Software zu entwickeln ist SQL eben das non-plus-ultra und nicht mehr RLA.
    Bei Client/Server-Szenarien geht soagar nur ausschließlich SQL.
    Und die Versuche mit SETOBJACC würde ich auch sein lassen, denn im realen Umfeld hast du 100te Tabellen mit z.T. Millionen von Sätzen, da ist ein SETOBJACC schlicht nicht möglich.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  6. #6
    Registriert seit
    Nov 2018
    Beiträge
    35
    Hi!

    Wir haben keinen Write-Cache am Controller (Single-Controller mit 2x550GB 10k Disk)

    Zweck der Analyse: Zu verstehen, was sich wie auf die Performance auswirkt. Es geht um 5250 Sessions, da nur dort diese Schwankungen auffallen.

    Zu SQL: Ist mir alles klar. Bei SQL ist das Problem (siehe mein andere Topic) noch viel extremer wegen der Optimizer,... Deshalb hab ich die Applikation zum Vergleich auf RLA umgebaut. War zeitlich vertretbar und es hat mich einfach interessiert, was da an Performance rausgeholt werden kann.

    Ich bin mit der Performance auch sehr zufrieden. Jetzt wollte ich noch klären, was hintern den seltenen, aber doch vorhanden Schwankungen steht.

    Das mit dem SETOBJACC kann ich so nicht als Problem sehen, da es sich bei unserem Produktivsystem ja um ein reales Umfeld handelt ;-) Unsere DB passt locker in den Speicher.

    Mir ist schon klar, dass es sich bei den beiden Topics von mir um theoretische Analysen handelt, aber meine Meinung nach ist es sinnvoll solche Charakteristiken wirklich zu verstehen. Es gibt genug Leute in unserer Branche die nur mit Halbwissen daherkommen.

    LG

  7. #7
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Das kann ich schon verstehen. Allerdings habe ich auch schon Anwendungen gesehen, die deshalb langsam waren, weil sie einfach zu viele Daten überlesen müssen an Stelle sich eine View/LF/Index aufzubauen, mit dem man direkt nur die benötigten Daten liest.
    Da ist eine Optimierung im Millisekundenbereich nicht so besonders zielführend.

    Und eine DB, die komplett in den Speicher passen soll erlebt man da auch eher selten.
    Ggf. haben deine Zugriffszeiten mit dem eigentlichen DB-Zugriff gar nichts zu tun sondern mit dem Verdrängungswettbewerb der Non-DB-Seiten. M.a.W., das Nachladen von Programmcode ist die Ursache, da zu viel Speicher durch den SETOBJACC-Pool blockiert ist.

    Hast du denn mal komplett ohne SETOBJACC getestet?
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

Similar Threads

  1. Debugging einer RPGLE Anwendung mit RDI 9.0.3.6
    By Radinator in forum IBM i Hauptforum
    Antworten: 13
    Letzter Beitrag: 28-11-18, 13:05
  2. RPG Programm durch Verwendung von DS für I/O Operationen
    By Radinator in forum NEWSboard Programmierung
    Antworten: 11
    Letzter Beitrag: 17-09-18, 17:50
  3. Remote Debugging unter Verwendung von RDI 9.6.0.3 funktioniert nicht
    By LasterOfDesaster in forum IBM i Hauptforum
    Antworten: 3
    Letzter Beitrag: 04-06-18, 09:59
  4. MD5-Hash Code auf Datenbank-File oder IFS-File
    By CaddyMajor in forum NEWSboard Programmierung
    Antworten: 2
    Letzter Beitrag: 07-04-15, 13:07
  5. Artikel: Berechtigungsprobleme bei Save-/Restore- Operationen?
    By NEWSolutions Redaktion in forum NEWSolutions artikel
    Antworten: 0
    Letzter Beitrag: 05-12-13, 06:55

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •