Symptom:
Die I/O Performance z.B. bei SAN Disk ist extrem schlecht. Anstelle von ca. 2500 IO/s erreichen wir gerade mal 50-70 I/O
Lösung:
Hier eine Idee wie wir bei einem weiteren Fall von ungenügender I/O Leistung den schuldigen Shadow-Set Member eventuell eruieren könnten.
Das System hat für jede FC Disk \"response time\" Statistikdaten in einem Ringbuffer.
Nach meiner Überlegung müsste die Disk mit den tendenziell grösseren (write) Antwortzeiten der Schuldige sein.
Mit
$ANA/SYSTEM
SDA> FC PERF/COMP \'disk\' (z.B. $1$DGA2053)
sehen wir die \"write\" und \"read\" \"response time\" Verteilung. Beim Vergleich der Daten der drei Member sollte es möglich sein den Verursacher zu erkennen.
Die Counter lassen sich mit
SDA> FC PERF/CL für alle Disk oder mit $1$DGA2567 für eine individuelle Disk zurücksetzen
Hier ein Beispiel.
SDA> fc perf/comp $1$dga2053
FibreChannel Disk Performance Data
----------------------------------
$1$dga2053 (write)
Using EXE$GQ_SYSTIME to calculate the I/O time
accumulated write time = 62744126us writes = 87098 total blocks = 589131
I/O rate is about 5 mb/sec
LBC <2ms <4ms <8ms <16ms <32ms <64ms <128ms
=== ======== ======== ======== ======== ======== ======== ========
1 16637 889 330 56 2 - - 17914
2 993 63 11 4 - - - 1071
4 4884 306 118 17 6 - - 5331
8 51020 5841 1268 129 12 1 1 58272
16 3427 308 65 9 - - - 3809
32 446 99 17 4 - - - 566
64 33 4 1 1 - - - 39
128 81 9 6 - - - - 96
SDA> fc perf/cl $1$dga2053
$1$DGA2053 performance matrices have been cleared.
SDA> fc perf/comp $1$dga2053
FibreChannel Disk Performance Data
----------------------------------
$1$dga2053 (read)
Using EXE$GQ_SYSTIME to calculate the I/O time
accumulated read time = 116861us
reads = 422
total blocks = 2653
I/O rate is less than 1 mb/sec
LBC <2ms <4ms
=== ======== ========
1 87 1 88
2 23 - 23
4 91 2 93
8 168 3 171
16 28 1 29
32 6 - 6
64 12 - 12
Nach meiner These müsste die verursachende Disk tendenziel eine höhere (write) I/O \"response time\" haben
Mit dem IO_LOAD Tool und nach dem zurücksetzen der Zähler kann die Analyse noch weiter verifiziert werden.
Mit /CSV lassen sich die Daten in ein CSV (comma separeted values) File ablegen.
Die Kalkulaton benutzt den OpenVMS System Timer der alle 1ms inkrementiert wird.
Werte kleiner als 1ms werden unter dem Label <2us aufgelisted.
Mit /RSCC (Read System Cycle Counter) kann eine zeitliche Auflösung bis 2us erreicht werden.
Dies ist aber nicht zu empfehlen weil dies zu zwei PAL Code Aufrufen pro I/O führt.
Mit dieser Methodik sollte es möglich sein den Schuldigen nicht erst nach dem dritten (worst case) Dismount eines Shadow Members zu eruieren.
