Workshop I/O-Analyse am Beispiel SVC und Storwize V7000, Teil 1

Eine Performance-Bottleneck-Analyse erspart Hardware-Updates

Seite: 3/3

Ein Blick in den Cache des Speicherpools sagt: Da ist was!

SVC segmentiert seinen Cache und teilt jedem Speicherpool (MDG) eine gewisse Menge Maximalcache zu. Der Vorteil aus dieser Segmentierung ist, dass die Pools untereinander abgeschottet sind und sich eine hohe Anforderung an Cache-Ressourcen im Speicherpool nur in dem jeweiligen Pool auswirkt.

Untersucht man den Cache des Speicherpools zum Zeitpunkt des Peaks, so findet man hier Auffälligkeiten, die deutlich auf Probleme hinweisen. (Abb. 6: Überlastzustand der Cache-Partition)

Bildergalerie
Bildergalerie mit 9 Bildern

Aus Abbildung 6 können einige wichtige Informationen herauslesen werden:

  • Im Zeitraum von 5:00 bis 6:30 Uhr war die Cache-Partition mit teilweise 103 Prozent komplett überlastet (grüne Kurve). Man sieht, dass der SVC sich in dieser Zeit intensiv um das Destaging der Daten bemüht hat. Mit bis zu 1700 IOPS wurden Datenpakete aus dem Cache auf den Backend-Speicher transferiert. Im Normalbetrieb wird aus dieser Cache-Partition mit nur 80 bis 120 IOPS destaged.
  • Von 6:30 bis 8:15 Uhr wurde das Destaging auf von 1700 auf 500 IOPS zurückgefahren. In dieser Zeit sieht man immer noch hohe Latenzzeiten im Backend Storage. Im Volume selbst treten durch den freigewordenen SVC Cache weniger Latenzprobleme auf.
  • Um 21:00 und 23:00 Uhr sieht man weitere Spitzen in der Cache-Auslastung. Allerdings wurde hier der SVC-Cache mit maximal 100 Prozent aufgefüllt, was die Destaging-Operationen lediglich auf 200 bis 350 IOPS erhöht hat.

Man kann jetzt von zwei Ursachen für die schlechten Antwortzeiten der betroffenen Volumes ausgehen: Das unterliegende Speichersystem ist durch das intensive Destaging der Daten aus dem Cache überlastet und konnten nicht mehr so schnell auf die Anfragen der anderen Volumes reagieren. Außerdem war der Cache zu mehr als 100 Prozent aufgebraucht und anderen Volumes konnte für ihre Operationen kein Cache mehr zugeteilt werden.

Der Überfüllung des Caches liegt ein Problem zugrunde, das man auf verschiedene Arten lösen kann. Die Ursache liegt darin begründet, dass in einer relativ kurzen Zeiteinheit große Datenvolumen von Servern geschrieben wurden, die beim Destaging nicht schnell genug vom angeschlossenen Speichersystem aufgenommen werden konnten.

Möglichen Lösungen sind:

  • 1. Reduzierung der Schreibgeschwindigkeit (vom Server langsamer schreiben)
  • 2. Verbesserung der Leistungsfähigkeit des angeschlossenen Speichers (aus SVC Cache schneller Daten destagen)
  • 3. Strukturelle Änderungen im Ablauf der Schreiboperationen (Prozesse zeitlich entzerren, Volumes isolieren)

Um hier die richtige Antwort zu finden, muss man jetzt herausfinden, welche Prozesse für das hohe Datenvolumen verantwortlich sind. Im nächsten Schritt werden daher die Volumes gesucht, die in dieser Zeit solche großen Datenmengen geschrieben haben. Wenn die Volumes gefunden sind, sollte es kein Problem sein, die entsprechenden Server und deren Prozesse genau zu lokalisieren.

Im zweiten Teil des Artikels untersucht Michael Pirker wie man das I/O-Bottleneck durch konzeptuelle Maßnahmen beseitigt.

Ressourcen:

BVQ Webseite

BVQ YouTube Filme

Dokumente auf IBM Developerworks

SVC Treff - das Forum der SVC User Group Deutschland

(ID:36533790)