☰

Nachteile der Verwendung der ZFS-Datensatzgröße 16 KB statt 128 KB

tag-icon • tag-icon zfs qemu performance-tuning
Nachteile der Verwendung der ZFS-Datensatzgröße 16 KB statt 128 KB

Ich verwende Proxmox auf einem dedizierten Server. Für die Produktion verwende ich immer noch ext4, habe mich aber entschieden, mit ZFS herumzuspielen.

Daher habe ich zwei separate ZFS-Speicherpools mit unterschiedlichen Datensatzgrößen erstellt:

  • 128 KB für alles außer MySQL/InnoDB
  • 16 KB für MySQL/InnoDB (weil 16 KB die von mir verwendete Standardseitengröße von InnoDB ist)

Ich habe diesen 16k-Pool hinzugefügt, um zu prüfen, ob er wirklich einen Unterschied für die Leistung der MySQL/InnoDB-Datenbanken macht. Und das stimmt. Ich habe etwa 40 % mehr Transaktionen pro Sekunde und 25 % geringere Latenz (ich habe dies gründlich getestet mitSysbenchUndtpcc).

Aus praktischen Gründen würde ich im Moment lieber einen großen Pool mit 16 KB Datensatzgröße anstelle von zwei separaten Teilen (16 KB und 128 KB) verwenden.Ich weiß, dass ich Subvolumes auf einem einzelnen ZFS-Pool erstellen und ihnen unterschiedliche Datensatzgrößen zuweisen kann, aber das möchte ich auch vermeiden. Ich ziehe es vor, dies über die Proxmox-GUI verwaltbar zu halten.

Meine Fragen:

  1. Welche Nachteile können auftreten, wenn ich anfange, für alles eine kleine Datensatzgröße (16 KB) statt 128 KB zu verwenden (dies war die Standardeinstellung bei Proxmox)?

  2. Verfügt das QEMU-Disk-Image über ein Äquivalent zu innodb_page_size? Wenn ja, welche Größe hat es?

    Ich habe versucht, es mit folgendem zu überprüfen qemu-img info:

     $ qemu-img info vm-100-disk-0.raw
 image: vm-100-disk-0.raw
 file format: raw
 virtual size: 4 GiB (4294967296 bytes)
 disk size: 672 MiB

Die Servernutzung ist:

  • Container für www/php (Tonnen kleiner Dateien, aber innerhalb einer Container-Festplattendatei)
  • Container für Java/Spring-Anwendungen (sie produzieren viele Protokolle)
  • Container für MySQL/InnoDB-Datenbanken (keine Erklärung erforderlich)
  • lokale Backup-/Wiederherstellungsvorgänge einschließlich Komprimierung von Backups
  • Herumspielen mit großen GZIP-Dateien (nicht täglich, niedrige Priorität)

Antwort1

Kurze Antwort:Es hängt wirklich von Ihrem erwarteten Anwendungsfall ab. Als allgemeine Regel gilt, dass die standardmäßige Datensatzgröße von 128 KB eine gute Wahl für mechanische Datenträger ist (bei denen die Zugriffslatenz von der Suchzeit + Rotationsverzögerung dominiert wird). Für einen reinen SSD-Pool würde ich wahrscheinlich 16 KB oder höchstens 32 KB verwenden (nur wenn Letzteres eine deutliche Steigerung der Komprimierungseffizienz für Ihre Daten bietet).

Lange Antwort:Bei einem HDD-Pool empfehle ich, die standardmäßige 128-KB-Datensatzgröße für Datensätze beizubehalten und auch für zvol eine 128-KB-Volblockgröße zu verwenden. Der Grund dafür ist, dass die Zugriffslatenz für eine 7,2-K-RPM-HDD von der Suchzeit dominiert wird, wasnichtSkalieren Sie mit Datensatzgröße/Volblockgröße. Lassen Sie uns ein wenig rechnen: Eine 7,2-K-Festplatte hat eine durchschnittliche Suchzeit von 8,3 ms, während das Lesen eines 128-K-Blocks nur ~1 ms dauert. Daher erscheint es verschwenderisch, einen Head-Seek (mit 8 ms+ Verzögerung) zu befehlen, um kleine 16-K-Blöcke zu lesen, insbesondere wenn man bedenkt, dass Sie bei kleineren Lese-/Schreibvorgängen immer noch durch die R/M/W-Latenz beeinträchtigt werden. Darüber hinaus bedeutet eine kleine Datensatzgröße einen größeren Metadaten-Overhead und eine schlechtere Komprimierung. Während InnoDB also 16-K-IOs ausgibt und man für einen dedizierten Datensatz eine Datensatzgröße von 16 K verwenden kann, um R/M/W und Schreibverstärkung zu vermeiden, würde ich für gemischt genutzte Datensätze (d. h. solche, die Sie nicht nur für die Datenbank selbst, sondern auch für allgemeinere Arbeitslasten verwenden) vorschlagen, bei 128 K zu bleiben, insbesondere unter Berücksichtigung der Komprimierungsauswirkungen einer kleinen Datensatzgröße.

Für einen SSD-Pool würde ich jedoch eine viel kleinere Volblockgröße/Datensatzgröße verwenden, möglicherweise im Bereich von 16-32 K. Der Grund dafür ist, dass SSDs eine viel geringere Zugriffszeit, aber eine begrenzte Ausdauer haben, sodass das Schreiben eines vollständigen 128-K-Blocks für kleinere Schreibvorgänge übertrieben erscheint. Darüber hinaus ist die durch eine große Datensatzgröße erforderliche IO-Bandbreitenverstärkung auf einem Gerät mit hohen IOPs viel besorgniserregender als moderne SSDs (d. h. Sie riskieren, Ihre Bandbreite zu sättigenVorErreichen des IOP-Limits).

Antwort2

Ich empfehle TuningFalls und wannSie stoßen auf ein Problem.

Die Datensatzgröße von ZFS ist standardmäßig auf 128 KB eingestellt. Dies ist für die meisten Konfigurationen und Anwendungen akzeptabel und gültig.

Ausnahmen hiervon sind:

  • Bei bestimmten Datenbankanwendungen kann ein kleinerer Wert angemessen sein.
    Der Nachteil ist, dass die Komprimierung weit weniger effektiv ist, was sich möglicherweise stärker auf die Leistung auswirkt als die höhere Transaktionsanzahl!!
  • große Medien-Workloads (z. B. Videobearbeitung); ein größerer Wert ist sinnvoll
  • spezifische Workloads, die außerhalb der normalen ZFS-Anwendungsfälle liegen

Wenn Sie meinen, dass die Leistung des Datenbank-Benchmarks bei einer bestimmten Datensatzgröße besser ist, verwenden Sie ihn!
Aber haben Sie mit einer realistischenNicht-BenchmarkingArbeitsbelastung, um sicherzustellen, dass Sie sich auf das Richtige einstellen?

Antwort3

Es wird empfohlen, gemäß der ZFS-Dokumentation selbst „recordsize=16K“ festzulegen.

https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Workload%20Tuning.html#innodb

EDIT: Ich habe diese Einstellung gerade rückgängig gemacht, nachdem ich sie für weniger als 12 Stunden auf einem Proxmox-Server für einen virtuellen Server mit einer ziemlich großen Datenbank (>60 GB Daten) geändert hatte. Der Server fiel bei der Datenanalyse deutlich zurück. Tatsächlich ist der 'z_rd_int_'-Prozesse sprangen von einer niedrigen CPU-Auslastung auf jeweils etwa 5 %, während die 'z_wr_int_' hat bei der Verarbeitung einen Rückgang der CPU-Auslastung erfahren - wahrscheinlich, weil weniger Daten verarbeitet wurden.

Die Änderung des Hash-Algorithmus auf edonr ( zfs set checksum=edonr vmpool) hatte jedoch einen positiven Einfluss: Es perf topwird nicht mehr SHA256TransformBlocksals oberste Kernelfunktion angezeigt.

Daher ist die Empfehlung nicht in allen Fällen gut – es kann auf den ursprünglichen Satz zurückgegriffen werden.

verwandte Informationen