ZFS-Tuning für Workloads mit zufälligem Zugriff (Random Access)

• Die Standardparameter von ZFS sind als Kompromiss zwischen sequenziellem und zufälligem Zugriff gesetzt
  • Wenn die Eigenschaften des Workloads klar bekannt sind, ist ein aggressiveres Tuning möglich
• Erklärung des Unterschieds zwischen sequenziellem und zufälligem Zugriff
  • Bei HDDs kann die Leistung bei zufälligem Zugriff wegen der Kopfbewegungen im Vergleich zu sequenziellem Zugriff um ein Vielfaches bis hin zu mehrere Hundert Male langsamer sein
  • Auch bei SSDs ist zufälliger Zugriff deutlich schneller geworden, aber sequenzieller Zugriff bleibt weiterhin effizienter
  • Workloads, die große Dateien der Reihe nach lesen, haben eine starke Tendenz zu sequenziellem Zugriff
  • Workloads, die viele kleine Dateien häufig lesen, neigen stark zu zufälligem Zugriff
• Einführung in Methoden zur Workload-Analyse
  • Logische Schlussfolgerung auf Basis von Code/Struktur
  • Berechnung der durchschnittlichen IO-Größe auf Basis von Durchsatz (bps) + IOs pro Sekunde (iops)
  • Analyse der IO-Größenverteilung auf Basis von zpool iostat -r
• Interpretation von zpool iostat -r
  • ind: Größe einzelner logischer Requests
  • agg: tatsächlich zusammengeführte und ausgeführte IO-Größe
  • Wenn agg größer als ind ist, bedeutet das, dass das Zusammenführen benachbarter IOs gut funktioniert
• Ergebnis der Analyse des Beispiel-Workloads
  • Anteil synchroner Lesezugriffe etwa 76 %
  • Mehr als 99 % der Lesezugriffe sind 32 KiB oder kleiner
  • Auch bei asynchronen Schreibzugriffen ist der Anteil kleiner IOs hoch
  • Insgesamt ein Workload mit sehr starker Tendenz zu zufälligem Zugriff
• zfs_prefetch_disable
  • ZFS lädt bei Erkennung eines sequenziellen Zugriffsmusters benachbarte Blöcke vorab in den ARC
  • Bei Workloads mit zufälligem Zugriff kann die Trefferquote des Prefetchings niedrig sein, sodass nur unnötige IOs zunehmen
  • Die Effizienz des Prefetchings kann auf Basis von arc_summary gemessen werden
  • Wenn die Trefferquote niedrig ist, kann zfs_prefetch_disable in Betracht gezogen werden
• recordsize
  • Der Standardwert ist 128K
  • Da im Beispiel-Workload der Großteil der IOs 32 KiB oder kleiner ist, kann eine kleinere recordsize sinnvoll sein
• Auswahl des optimalen Werts
  • Wichtig ist die Entscheidung auf Basis von Benchmarks
  • Für Datenbanken wie MySQL/Postgres gibt es bereits viele bewährte Tuning-Beispiele
  • Häufig wird allgemein eine recordsize verwendet, die der Seitengröße der Datenbank ähnelt