Collect Performance Data

[andreaspr@aon.at]

Naja, du hattest ja geschrieben, dass du mit Native I/O arbeitest und nicht mit SQL.
Deshalb gibt es beim STRDBMON nicht viel zu sehen.

Hast du schon die Aktivität der Offene Dateien während der Ausführung beobachtet, ob, wieviel und wie schnell sich da was tut?
Daran könnte man eventuell erkennen ob er ab und zu längere Pausen macht, nur sehr langsam arbeitet oder einfach sehr viel zu arbeiten hat.

[KingofKning]

Das ist aber doof.
Es kann doch eigentlich nicht sein das die Kiste für die Programmiersprachen kein Analyestool hat.
SQL dürften doch die wenigsten machen.

Ich hatte mir die offenen Dateien angesehen, konnte da aber für mich persönlich nichts interessantes entdecken.

Habe halt auf der AS/400 nur wenig programmiert....

GG

[andreaspr@aon.at]

Was du machen kannst ist, im PGM an bestimmten stellen einen Timestamp in eine Tabelle auszugeben.
Dadurch kannst du herausfinden welche(r) Prozess(e) so lange benötigen und dann die einzelnen Stellen genauer analysieren.
Aber vielleicht gibt es eine viel einfachere Variante die ich auch noch nicht kenne.
Das ist jedoch sicher einer der vielen Vorteile die SQL mit sich bringt!

[Christian Bartels]

Wenn das Produkt 57xxPT1 ("Performance Tools") installiert ist, würde ich folgendes machen:

1. Für den Zeitraum des Programmlaufes das Performance Collection Interval auf 5 Minuten oder weniger stellen (CFGPFRCOL) und die Performance Collection starten (STRPFRCOL).

2. Wenn das Programm fertig ist, die Performance-Daten für den betroffenen Job anzeigen: STRPFRT -> Auswahl 7 ("Display performance data") -> das passende Member auswählen (vermutlich das oberste) -> die Intervalle auswählen, in denen das Programm lief -> F6 ("Display all jobs") -> Auswahl 5 ("Display job detail") und Auswahl 6 ("Wait detail").

Hiermit kann man eine erste Idee bekommen, wo es klemmt. Aus den Job Details kann man z.B. die CPU-Sekunden sehen und in Bezug auf die Intervall-Länge bringen. Außerdem kann man sehen, ob es eventuell Übergänge nach "Ineligible" (nicht auswählbar) gab. Aus den Wait Details kann man sehen, wie viele Page-Faults und Lock-Waits es gab, und eventuell andere Wartezeiten.

Parallel dazu kann man sich über die Performance-Reports noch ansehen, wie das Paging insgesamt war, und welche Platten-Antwortzeiten es gab (System-Report).

Damit sollte man erstmal sagen können, womit der Job seine Zeit verbraucht (CPU, Warten auf Page-Faults, Sperren, "langsame" Platten, freie Activity-Slots im Pool oder sonst irgendwas). Abhängig davon kann man die nächsten Schritte planen.

Mit freundlichen Grüßen,
Christian Bartels.

[KingofKning]

Hallo,
danke für die Info, werde ich am Sonntag mal ausprobieren.

GG

[KingofKning]

Hallo,
ich hatte es mal gestern Abend laufen lassen, aber etwas erkennen kann ich da auch nicht:


Job CPU Tns Avg Disk
Option Job User Number Type Util Count Rsp I/O
MOABVERGL GXXXXXXX 491269 BCH 2,73 0 0,0 43469


Job CPU Tns Avg Disk
Option Job User Number Type Util Count Rsp I/O
MOABVERGL GXXXXXXX 491269 BCH 2,73 0 0,0 43469

Wait Wait
Category Time
------------------------------------------------- ----------
Reserved 5
DASD (page faults) 8
DASD (other) 79

O Int
p -Transaction- -CPU Util-- Feat --High-- Pool Fault Excp
t Date Time Count Rsp Tot Int Bch Util Dsk Unit Mch Usr ID Util
21.04 16:20 195 0,03 6 0 6 0 14 0002 8 29 02 0
21.04 16:25 227 0,04 5 0 5 0 18 0003 4 47 02 0
21.04 16:30 287 0,03 4 0 4 0 15 0004 1 31 02 0


Start date . . . . : 21.04.10 Serial number . . : 69-XXYY2
Start time . . . . : 16:17:57 Feature Code . . . : 7790-8330
Partition ID . . . : 001 Int Threshold . . : 100.00 %
QPFRADJ . . . . . : 2 Virtual Processors : 1
QDYNPTYSCD . . . . : 1 Processor Units . : 1,00
QDYNPTYADJ . . . . : 1

CPU utilization (interactive) . . . . . . . . . : 0,61
CPU utilization (other) . . . . . . . . . . . . : 5,75
Interactive Feature Utilization . . . . . . . . : 0,41
Time exceeding Int CPU Threshold (in seconds) . : 0
Job count . . . . . . . . . . . . . . . . . . . : 75
Transaction count . . . . . . . . . . . . . . . : 195
Transactions per hour . . . . . . . . . . . . . : 5850
Average response (seconds) . . . . . . . . . . . : 0,03
Disk utilization (percent) . . . . . . . . . . . : 11,82
Disk I/O per second . . . . . . . . . . . . . . : 513,1
Logical DB I/O for DDM jobs . . . . . . . . . . : 0

Ich werde das jetzt nochmal laufen lassen wenn die Kiste gerade ein IPL gefahren hat, da ist sie ja fast doppelt so schnell und denn mal die Performance auswerten.

GG

[Christian Bartels]

Aus den angegebenen Daten fällt mir nur auf, daß im ersten Intervall (21.04 16:20) relativ viele Page-Faults im Machine-Pool sind (8 Faults/Sekunde ist schon recht viel). Was mir fehlt, ist die Auswahl 5 vor dem betroffenen Job, hier besonders die Anzahl der CPU-Sekunden für den Job und die Übergänge nach Ineligible (falls gegeben) in den drei Intervallen.

Man sieht, daß es relativ viel Disk I/O gab (43469 Operationen mit einer Gesamtwartezeit von 79 Sekunden), d.h. aber auch, daß die durchschnittlichen Plattenantwortzeiten mit 1,8 ms in Ordnung sind. Ist sichergestellt, daß sich die zu verarbeitende Datenmenge nicht wesentlich verändert hat?

Mit freundlichen Grüßen,
Christian Bartels.

[AS400.lehrling]

Heist PagaFault nicht einfach nur das sich die Information noch nicht im Cache Befindet und daher von der Disk gelesen werden muss ?

Gruß AS400.lehrling

[KingofKning]

Das ist korrekt, und da unsere Kiste auch nur 4 Gig Ram Speicher hat nicht wirklich ungewöhnlich.

Werde wie schon gesagt das ganze am Wochende nochmals wiederholen.

GG