Oracle Commit Performance – Filesystem I/O

Wenn man im SAP System feststellt, dass die Commit Performance unter steigender Last immer schlechter wird muss das nicht zwangsläufig etwas mit falscher Parametrisierung der Oracle Datenbank zu tun haben. SAP gibt in den EWA (Early Watch Alert) Berichten eine Indikation für Performanceprobleme mit an. So sind durchschnittliche Zeiten von <=15ms noch OK. Was aber tun wenn hier 20 oder mehr ms angegeben werden. Gerade in einem stark ausgelasteten ERP System kann sich dieser Umstand recht schnell negativ auf die Performance auswirken und zieht sich somit durch das komplette System.

Um zu sehen wie es um die Waits steht gibt es im Oracle und SAP mehrere Wege nach Rom. Ich nutze oft den AWR Workloard Report über die TX DB02:

AWR Report Wait Class
AWR Report Wait Class

Alternativ kann man auch direkt im Oracle schauen:

set pages 200 lines 200
select  WAIT_CLASS,
 TOTAL_WAITS,
 round(100 * (TIME_WAITED / SUM_TIME),2) PCT_TIME
 from
 (select WAIT_CLASS,
 TOTAL_WAITS,
 TIME_WAITED
 from    V$SYSTEM_WAIT_CLASS
 where   WAIT_CLASS != 'Idle'),
 (select  sum(TOTAL_WAITS) SUM_WAITS,
 sum(TIME_WAITED) SUM_TIME
 from    V$SYSTEM_WAIT_CLASS
 where   WAIT_CLASS != 'Idle')
 order by 3 desc;
WAIT_CLASS                                                       TOTAL_WAITS   PCT_TIME
 ---------------------------------------------------------------- ----------- ----------
 System I/O                                                         246768191      33.53
 User I/O                                                            84937746      29.43
 Commit                                                              26410809      23.67
 Administrative                                                      18449134      10.89
 Application                                                          2826515       1.11
 Network                                                           1587402009        .96
 Other                                                                1035082         .3
 Concurrency                                                           875457        .08
 Configuration                                                           8637        .01
9 rows selected.

In dem Screenshot sieht man, dass die Commit Zeiten in dem untersuchten System fast 1/3 der kompletten DB Zeit stellen und mit 33ms mehr als doppelt so hoch liegen wie die von der SAP als bedenkliche Indikation festgelegten 15ms. Es besteht also Handlungsbedarf. Sofern die Oracle Parameter geprüft sind und auch die Konfiguration der Redologgruppen und Member (Anzahl, Größe) zutreffend sind muss man etwas tiefer ins System einsteigen.

1) Performance Filesysteme

Hier sollte sichergestellt sein, dass die Anbindung an den Storage kein Engpass ist. Die Filesysteme von origlog*/mirlog* sollten jeweils auf einzelnen Platten liegen um bestmöglichen I/O und kurze Latenzen zu ermöglichen

2) Das Filesystemlayout

Oftmals vergessen und total unterschätzt ist das Layout des Filesystems – also dessen Alignment. Ist hier etwas nicht korrekt eingerichtet kann die verwendete Hardware noch so schnell sein, es stellen sich trotzdem unter hoher Last negative Performance Effekte ein. Im zugegeben schon etwas älteren SAP Hinweis #323270 ist dies für die verschiedenen Betriebssystemarchitekturen beschrieben. In dem Hinweis ist eine Auflistung für die verschiedenen Architekturen enthalten:

Windows NT -> 512 Bytes
 Solaris -> 512 Bytes
 AIX -> 512 Bytes
 HP-UX -> 1024 Bytes
 Digital Unix -> 1024 Bytes

Das bedeutet, dass die Log Block Size von X Byte in die Datei geschrieben wird. Wenn jetzt ein Filesystem mit einer anderen Blocksize angelegt wurde kommt es zu fragmentierungen der Blöcke, da die Informationen Größer oder Kleiner als die Blöcke sein können und somit unnötig I/O generiert wird (Entweder es wird zu viel gelesen oder zu viel geschrieben). Wenn Beispielsweise ein Dateisystem mit 4K Blockgröße angelegt wurde und die Redologs in 512 Byte Happen geschrieben werden muss bei jedem schreiben ein 4K Block für die 512 Byte Informationen belegt werden. Andersherum wird beim lesen eines 512 Byte Happen der ganze 4K Block von der Platte gelesen. Noch schlimmer wäre es z.B, wenn die Filesystemeinstellung ein Alignment von 512 Bytes hat und die Log Block Size im Oracle aber auf 1024 Bytes eingestellt ist. Für jeden logischen Oracle Block in der Redolog Datei würden dann 2 I/Os auf dem Filesystem benötigt, da die Information nicht in einem einzigen Block abgelegt werden kann. Auch wenn sich das bei heutiger Technik und Leistungsfähigkeit der SAN System eher unwichtig anhört darf man nicht vergessen, dass dies bei jedem Commit mehrfach passiert.

Im Oracle kann man das eingestellte Alignment für die Log Block Size wie folgt auslesen:

SQL> select max(lebsz) log_block_size from x$kccle where inst_id = userenv('Instance');

LOG_BLOCK_SIZE
--------------
           512

SQL>

Nun sollte also geprüft werden, dass die Filesysteme für die Redologs mit dem gleichen Alignment angelegt wurden. Ansonten wird hier sehr viel Overhead (demoted I/O) produziert. Demoted I/O bedeutet hier, dass auf die (langsamere) normale I/O Varinate zurück geschlatet wird,  wenn direct I/O oder concurrent I/O zuvor fehlgeschlagen sind. Wenn man also direct I/O oder wie in der Regel als Default vom Oracle (11.2.0.3) bei AIX  6.1 genutzt concurrent I/O für die Zugriffe nutzt und die Log Block Size nicht mit dem FS Alignement zusammen passt sieht das so aus:

bash >trace -aj 59B,59C; sleep 1; trcstop
bash >trcrpt -o redlog_zugriff.txt
bash >grep demoted redlog_zugriff.txt
59B     0.002085550       0.031898                   JFS2 IO dio demoted: vp = F1000A0408682020, mode = 0001, bad = 0002, rc = 0000, rc2 = 0000
59B     0.002144787       0.023143                   JFS2 IO dio demoted: vp = F1000A0408672020, mode = 0001, bad = 0002, rc = 0000, rc2 = 0000
59B     0.004384119       0.038100                   JFS2 IO dio demoted: vp = F1000A0408672020, mode = 0001, bad = 0002, rc = 0000, rc2 = 0000
59B     0.004484242       0.041274                   JFS2 IO dio demoted: vp = F1000A0408682020, mode = 0001, bad = 0002, rc = 0000, rc2 = 0000

Hier zeigt sich, dass absolut jeder I/O auf die Files auf das normale I/O zurückgestuft wird. Das ist natürlich der Performance nicht zuträglich. Oracle schreibt in diesem Beispiel mit der angegebenen Log Block Size von 512 Bytes, das Filesystem hat jedoch eine Blocksize von 4096 Bytes.

IBM hat 2012 einen Performanceguide für Oracle unter AIX herausgebracht in dem dieses Thema ebenfalls anschaulich erläutert wird. Anbei eine wie ich finde sehr aussagekräftige Veranschaulichung welche Auswirkungen ein demoted I/O auf die Antwortzeit hat (ORA: 512 Bytes, FS: 4096 Bytes):

Performance Guide von IBM, Screenshot seite 40.
Performance Guide von IBM, Screenshot Seite 40.

Der Unterschied zwischen direct I/O und dem normalen I/O beträgt satte 26ms oder anders ausgedrückt ist um Faktor 14 (!) langsamer. Bei Nutzung von CIO (cuncurrent I/O) sieht das wieder anders aus. Daher die dringende Empfehlung die Filesysteme mit dem richtigen Alignment anzulegen und schon klappts auch mit dem I/O 😉

Stellt sich oftmal die Frage woher kommen die 4K im FS? Zum einen könnte es schlichtweg Unwissenheit sein, zum anderen könnte es daran liegen, dass es die Standard Größe für das Alignment beim Anlegen des Filesystems ist.

Bei den Datafiles gibt es daher diese Probleme in der Regel nicht. Hier ist die Regel, dass wenn die Oracle Block Size >=4K ist, das Alignment des FS ebenfalls 4K sein soll. Wie die Blocksize eingestellt ist lässt sich im Oracle wie folgt ermitteln:

SQL> show parameter db_block_size
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_block_size                        integer     8192
SQL>

Hier ist die DB Blocksize entsprechend auf 8K eingestellt (Standard, Oracle für SAP).

Für AIX kann man das Filesystem Alignment („Block Size“) mit dem Befehl lsfs -q <Filesystem> ermitteln:

server:/root # lsfs -q /oracle/SAP/sapdata1
Name            Nodename   Mount Pt               VFS   Size    Options    Auto Accounting
/dev/lvsapdata1 --         /oracle/SAP/sapdata1   jfs2  4156555264 rw,noatime yes  no
  (lv size: 4156555264, fs size: 4156555264, block size: 4096, sparse files: yes, inline log: yes, inline log size: 1982, EAformat: v1, Quota: no, DMAPI: no, VIX: yes, EFS: no, ISNAPSHOT: no, MAXEXT: 0, MountGuard: no)
server:/root #

About the author