Security ist ein stets aktuelles Thema in der IT. Deshalb widmet sich das ADMIN-Magazin 04/2012 speziell Sicherheitsaspekten und gibt Antworten auf die Fragen: ... (mehr)

Performance

Performance-Messungen mit Caching-Technologien sind schwierig durchzuführen. Vor allem der Weg zu einem definierten Ausgangszustand ist holprig. Die erste Hürde stellt sich bereits bei der Auswahl eines geeigneten Benchmark-Werkzeugs. Der flexible I/O-Tester Fio meistert sie glänzend, er wurde bereits im ADMIN 05/2011 vorgestellt [6].

Die Fio-Testdateien auszuwählen, gestaltet sich ebenfalls als schwierig: Im Echtbetrieb wird es selten der Fall sein, dass Daten, die gerade geschrieben worden sind, sofort wieder gelesen werden. Genau dieses Verhalten simulieren aber die meisten Performance-Tests. Im Falle von Flashcache beeinflusst dieses Testsetup nachweislich die Testergebnisse: Nach dem Auslegen der Testdaten auf das Volume beginnt Flashcache mit dem Dirty Cleaning. Diese I/O-Operationen des Hintergrund-Prozesses wirken sich auf darauffolgende Lese-Tests aus. Um eine reale Gschwindigkeits-Messung zu erhalten, müssen die Tests erst dann durchgeführt werden, wenn die Synchronisation abgeschlossen ist, ansonsten muss das Dirty Cleaning zumindest als Faktor bei den Ergebnissen bedacht werden. Details zum verwendeten Testsetup sind im gleichnamigen Kasten zu finden.

Testsetup

Das Testsetup setzt sich aus folgenden Komponenten zusammen:

  • Intel(R) Xeon(R) CPU E5502 @ 1.87GHz sowie 12 GByte RAM
  • Intel Series 320 160 GByte, via Host-protected-Area (HPA), reduziert auf 32 GByte. Die Reduzierung wurde vor allem für die Verkürzung der Performance-Tests vorgenommen. Normalerweise erfolgt die Limitierung mittels HPA nur auf 70 bis 80 Prozent [7]
  • 2 TByte Western Digital WD2002FYPS Festplatte
  • Flashcache Git Commit: 1.0-148-g332fe0fc55ca
  • Fio in der Version 2.0.7
  • Ubuntu 12.04 mit den neuesten Updates

Die Fio-Tests setzen sich aus sequenziellem Lesen/Schreiben (1 MByte Blockgröße) und zufälligem Lesen/Schreiben (4 KByte Blockgröße) zusammen (siehe auch Abbildung 3 und 4). Alle Tests beinhalten die Verwendung des Page Cache, daraus Profit schlagen aber nur die Schreib-Tests, da Fio beim Lesen den Page Cache vor dem Test invalidiert.

Abbildung 3: Sequenzieller Lese-/Schreib-Test mit Flashcache.
Abbildung 4: Zufälliger (Random) Lese-/Schreib-Test mit Flashcache.

Fast wie SSD

Bei jenen sequenziellen Tests, bei denen sich das Daten-Set komplett auf der SSD befindet, kommt Flashcache auch an die Performance einer reinen SSD heran. Die grünen Punkte in den Abbildungen markieren jeweils die Geschwindigkeiten der Tests mit einer reinen SSD, ohne Flashcache. Ab 32 GByte Set-Größe passen nicht mehr alle Test-Daten auf die SSD. Aufgrund von Filesystem- und Flashcache-Metadaten müssen einige 100 MByte auf die Festplatte ausgelagert werden. Die Performance bei 64 GByte sinkt auf etwa 150 MByte pro Sekunde – immerhin noch 40 MByte über der durchschnittlichen Geschwindigkeit der Festplatte.

Die zufälligen Tests bestätigen die Vorteile des Page Cache, selbst bei 64 GByte Random Write werden noch 1470 IOPS erreicht. Randomread fällt bereits bei 32 GByte auf circa 1000 IOPS zurück, bei 64 GByte zeigt sich eine drastische Reduzierung auf 182 IOPS. Für diese Einbrüche gibt es mehrere Gründe. In erster Linie übersteigt ab 32 GByte die Daten-Set-Größe die Größe der SSD, die Größe des RAMs spielt beim Lesen keine Rolle, da der Page Cache nicht eingreift. Des Weiteren wurden die Fio-Tests ohne die Option »norandommap« aufgerufen, das heißt ein einmal gelesener Block wird nicht noch ein zweites Mal gelesen. Zu Beginn des Tests liegen bei einem 64 GByte Daten-Set circa die Hälfte auf der SSD. Fordert Fio einen zufälligen Block an, der auf der HDD liegt, wird dieser gelesen, und Flashcache cacht den Block auf der SSD. Dadurch ersetzt Flashcache einen Block auf der SSD, den Fio zum späteren Zeitpunkt vom Cache lesen hätte können. Den neuen, soeben gelesenen Block im Cache wird Fio nicht mehr benötigen, da er bereits einmal gelesen wurde.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019