Langsames sequentielles Lesen des ZFS-Pools

Ich habe eine verwandte Frage zu diesem Problem, aber sie wurde zu kompliziert und zu groß. Deshalb habe ich beschlossen, das Problem in NFS- und lokale Probleme aufzuteilen. Ich habe auch versucht, dies auf der zfs-Diskussion-Mailingliste zu erfragen, ohne großen Erfolg.

Langsames Kopieren zwischen NFS / CIFS-Verzeichnissen auf demselben Server

Überblick: Wie ich eingerichtet bin und was ich erwarte

1. Ich habe einen ZFS-Pool mit 4 Festplatten. 2 TB ROT konfiguriert als 2 gestreifte Spiegel (RAID 10). Unter Linux zfsonlinux. Es gibt keine Cache- oder Protokollgeräte.
2. Die Daten werden spiegelübergreifend verteilt (wichtig für ZFS).
3. Jede Festplatte kann parallel mit 147 MB ​​/ s (roh w / dd) lesen, was einen kombinierten Durchsatz von 588 MB / s ergibt.
4. Ich erwarte etwa 115 MB / s Schreiben, 138 MB / Sek. Lesen und 50 MB / Sek. Umschreiben von sequentiellen Daten von jeder Festplatte, basierend auf Benchmarks einer ähnlichen 4 TB RED-Festplatte. Ich erwarte nicht weniger als 100 MB / s Lesen oder Schreiben, da jede Festplatte dies heutzutage kann.
5. Ich dachte, ich würde eine 100% ige E / A-Auslastung auf allen 4 Festplatten sehen, wenn unter Last sequentielle Daten gelesen oder geschrieben werden. Und dass die Festplatten bei 100% Auslastung mehr als 100 MB / s ausgeben würden.
6. Ich dachte, der Pool würde mir ungefähr 2x Schreib-, 2x Umschreib- und 4x Leseleistung über eine einzelne Festplatte bieten - irre ich mich?
7. NEU Ich dachte, ein ext4 zvol im selben Pool würde ungefähr die gleiche Geschwindigkeit wie ZFS haben

Was ich eigentlich bekomme

Ich finde, dass die Leseleistung des Pools bei weitem nicht so hoch ist, wie ich erwartet hatte

Bonnie ++ Benchmark auf Pool von vor ein paar Tagen

Version 1.97 ------ Sequenzielle Ausgabe ------ - Sequenzielle Eingabe- - Zufällige-
Parallelität 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Maschinengröße K / s% CP K / s% CP K / s% CP K / s% CP K / s% CP / s% CP
igor 63G 99 99 232132 47 118787 27 336 97 257072 22 92.7 6

bonnie ++ auf einem einzelnen 4 TB RED-Laufwerk allein in einem Zpool

Version 1.97 ------ Sequenzielle Ausgabe ------ - Sequenzielle Eingabe- - Zufällige-
Parallelität 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Maschinengröße K / s% CP K / s% CP K / s% CP K / s% CP K / s% CP / s% CP
igor 63G 101 99 115288 30 49781 14 326 97 138250 13 111.6 8

Demnach sind die Lese- und Umschreibgeschwindigkeiten basierend auf den Ergebnissen eines einzelnen 4-TB-RED-Laufwerks angemessen (sie sind doppelt). Die erwartete Lesegeschwindigkeit hätte jedoch etwa 550 MB / s betragen (4x die Geschwindigkeit des 4-TB-Laufwerks), und ich würde zumindest auf etwa 400 MB / s hoffen. Stattdessen sehe ich ungefähr 260 MB / s

bonnie ++ auf dem Pool von gerade jetzt, während die folgenden Informationen sammeln. Nicht ganz das Gleiche wie zuvor, und nichts hat sich geändert.

Version 1.97 ------ Sequenzielle Ausgabe ------ - Sequenzielle Eingabe- - Zufällige-
Parallelität 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Maschinengröße K / s% CP K / s% CP K / s% CP K / s% CP K / s% CP / s% CP
igor 63G 103 99 207518 43 108810 24 342 98 302350 26 256,4 18

zpool iostat beim schreiben. Scheint mir in Ordnung zu sein.

                                                 Bandbreite des Kapazitätsbetriebs
Pool zuweisen frei lesen schreiben lesen schreiben
---------------------------------------- ----- - ---- ----- ----- ----- -----
pool2 1.23T 2.39T 0 1.89K 1.60K 238M
  Spiegel 631G 1.20T 0 979 1.60K 120M
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 0 1007 1,60 K 124M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 0 975 0 120M
  Spiegel 631G 1.20T 0 953 0 117M
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 - - 0 1,01 K 0 128M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 0 953 0 117M

zpool iostat beim umschreiben. Scheint mir in Ordnung zu sein, denke ich .

                                                 Bandbreite des Kapazitätsbetriebs
Pool zuweisen frei lesen schreiben lesen schreiben
---------------------------------------- ----- - ---- ----- ----- ----- -----
pool2 1.27T 2.35T 1015 923 125M 101M
  Spiegel 651G 1.18T 505 465 62.2M 51.8M
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 198 438 24,4 M 51,7 M.
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 306 384 37,8M 45,1M
  Spiegel 651G 1.18T 510 457 63.2M 49.6M
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 - - 304 371 37,8 M 43,3 M.
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 206 423 25,5 M 49,6 M.

Hier frage ich mich, was los ist

zpool iostat beim lesen

                                                 Bandbreite des Kapazitätsbetriebs
Pool zuweisen frei lesen schreiben lesen schreiben
---------------------------------------- ----- - ---- ----- ----- ----- -----
pool2 1.27T 2.35T 2.68K 32 339M 141K
  Spiegel 651G 1.18T 1.34K 20 169M 90.0K
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 748 9 92,5 M 96,8 K.
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 623 10 76,8M 96,8K
  Spiegel 651G 1.18T 1.34K 11 170M 50.8K
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 - - 774 5 95,7 M 56,0 K.
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 599 6 74,0M 56,0K

iostat -x während des gleichen Lesevorgangs . Beachten Sie, dass IO% nicht bei 100% liegt.

Gerät: rrqm / s wrqm / sr / sw / s rkB / s wkB / s avgrq-sz avgqu-sz warten auf r_await w_await svctm% util
sdb 0,60 0,00 661,30 6,00 83652,80 49,20 250,87 2,32 3,47 3,46 4,87 1,20 79,76
sdd 0,80 0,00 735,40 5,30 93273,20 49,20 251,98 2,60 3,51 3,51 4,15 1,20 89,04
sdf 0,50 0,00 656,70 3,80 83196,80 31,20 252,02 2,23 3,38 3,36 6,63 1,17 77,12
sda 0,70 0,00 738,30 3,30 93572,00 31,20 252,44 2,45 3,33 3,31 7,03 1,14 84,24

Einstellungen für zpool und Testdatensatz:

• atime ist aus
• Komprimierung ist ausgeschaltet
• ashift ist 0 (autodetect - mein Verständnis war, dass dies in Ordnung war)
• Laut zdb sind alle Festplatten Ashift = 12
• Modul - Optionen zfs zvol_threads = 32 zfs_arc_max = 17179869184
• Sync = Standard

Bearbeiten - 30. Oktober 2015

Ich habe noch ein paar Tests gemacht

• Datensatz bonnie ++ w / recordsize = 1M = 226MB schreiben, 392MB viel besser lesen
• Datensatz dd w / Datensatzgröße = 1M = 260MB schreiben, 392MB viel besser lesen
• zvol w / ext4 dd bs = 1M = 128MB schreiben, 107MB lesen warum so langsam?
• Datensatz 2 Prozessess parallel = 227 MB Schreiben, 396 MB Lesen
• dd direct io unterscheidet sich nicht im Datensatz und im zvol

Ich bin viel zufriedener mit der Leistung mit der erhöhten Rekordgröße. Fast jede Datei im Pool ist weit über 1 MB groß. Also lasse ich es so. Die Festplatten werden immer noch nicht zu 100% ausgelastet, weshalb ich mich frage, ob sie noch viel schneller sein könnten. Und jetzt frage ich mich, warum die zvol-Leistung so mies ist, da ich das (leicht) benutze.

Gerne gebe ich die in den Kommentaren / Antworten angeforderten Informationen weiter. In meiner anderen Frage sind auch unzählige Informationen enthalten: Langsames Kopieren zwischen NFS / CIFS-Verzeichnissen auf demselben Server

Ich bin mir völlig bewusst, dass ich etwas einfach nicht verstehe und dass dies möglicherweise überhaupt kein Problem ist. Danke im Voraus.

Um es klar zu machen, lautet die Frage: Warum ist der ZFS-Pool nicht so schnell wie erwartet? Und vielleicht stimmt noch etwas nicht?

Ich habe es geschafft, Geschwindigkeiten zu erreichen, die den erwarteten Zahlen sehr nahe kommen.

Ich suchte nach 400 MB / s und schaffte 392 MB / s . Also ich sage das ist Problem gelöst. Mit dem späteren Hinzufügen eines Cache-Geräts schaffte ich das Lesen mit 458 MB / s (zwischengespeichert, glaube ich).

1. Dies wurde zunächst einfach durch Erhöhen des ZFS-Datensatzwerts recordsizeauf erreicht1M

zfs set recordsize=1M pool2/test

Ich glaube, diese Änderung führt nur zu weniger Festplattenaktivität und damit zu effizienteren großen synchronen Lese- und Schreibvorgängen. Genau das, wonach ich gefragt habe.

Ergebnisse nach der Änderung

• bonnie ++ = 226 MB schreiben, 392 MB lesen
• dd = 260 MB Schreiben, 392 MB Lesen
• 2 Prozesse parallel = 227 MB Schreiben, 396 MB Lesen

2. Ich habe es noch besser geschafft, als ich ein Cache-Gerät (120 GB SSD) hinzugefügt habe. Das Schreiben ist etwas langsamer, ich bin mir nicht sicher warum.

Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
igor            63G           208325  48 129343  28           458513  35 326.8  16

Der Trick mit dem Cache-Gerät bestand darin, l2arc_noprefetch=0in /etc/modprobe.d/zfs.conf festzulegen . Es ermöglicht ZFS, Streaming- / sequentielle Daten zwischenzuspeichern. Tun Sie dies nur, wenn Ihr Cache-Gerät schneller ist als Ihr Array, wie meines.

Nachdem ich von der Änderung der Datensatzgröße in meinem Dataset profitiert hatte, dachte ich, dass dies ein ähnlicher Weg sein könnte, um mit einer schlechten zvol-Leistung umzugehen.

Ich bin auf mehrere Leute gestoßen, die erwähnt haben, dass sie mit a eine gute Leistung erzielt haben volblocksize=64k, also habe ich es versucht. Kein Glück.

zfs create -b 64k -V 120G pool/volume

Aber dann habe ich gelesen, dass ext4 (das Dateisystem, mit dem ich getestet habe) Optionen für RAID wie strideund unterstützt stripe-width, die ich noch nie zuvor verwendet habe. Daher habe ich diese Site verwendet, um die erforderlichen Einstellungen zu berechnen: https://busybox.net/~aldot/mkfs_stride.html und das zvol erneut formatiert.

mkfs.ext3 -b 4096 -E stride=16,stripe-width=32 /dev/zvol/pool/volume

Ich lief bonnie++, um einen einfachen Benchmark durchzuführen, und die Ergebnisse waren ausgezeichnet. Ich habe die Ergebnisse leider nicht bei mir, aber sie waren mindestens 5-6x schneller für Schreibvorgänge, wie ich mich erinnere. Ich werde diese Antwort erneut aktualisieren, wenn ich erneut einen Benchmark durchführe.

Ihre Ergebnisse sind durchaus vernünftig, Ihre Erwartungen jedoch nicht: Sie übertreiben die Verbesserung der Leseleistung durch RAID1 (und im weiteren Sinne durch RAID10). Der Punkt ist, dass eine 2-Wege-Spiegelung höchstens das Zweifache der Lesegeschwindigkeit / IOPs der einzelnen Festplatte ergibt, die tatsächliche Leistung jedoch zwischen 1 und 2 liegen kann.

Lassen Sie uns anhand eines Beispiels klarstellen. Stellen Sie sich ein System mit 2-Wege-Spiegel vor, bei dem jede Festplatte 100 MB / s (sequentiell) und 200 IOPS unterstützt. Bei einer Warteschlangentiefe von 1 (maximal eine einzelne ausstehende Anforderung) hat dieses Array keinen Vorteil gegenüber einer einzelnen Festplatte: RAID1 teilt E / A-Anforderungen in die Warteschlange der beiden Festplatten auf, teilt jedoch keine einzelne Anforderung auf zwei Festplatten auf (zumindest nicht) Jede Implementierung, die ich gesehen habe, verhält sich so. Auf der anderen Seite ist der Gesamtdurchsatz der Festplatte erheblich höher als bei einer einzelnen Festplatte, wenn Ihre E / A-Warteschlange größer ist (z. B. 4/8 ausstehende Anforderungen).

Ein ähnlicher Punkt kann für RAID0 ausgeführt werden. In diesem Fall hängt die durchschnittliche Verbesserung jedoch nicht nur von der Warteschlangengröße, sondern auch von der E / A-Anforderungsgröße ab : Wenn Ihre durchschnittliche E / A-Größe kleiner als die Blockgröße ist, wird sie nicht gestreift auf zwei (oder mehr) Festplatten, aber es wird von einer einzigen bedient. Ihre Ergebnisse mit der vergrößerten Bonnie ++ - Datensatzgröße zeigen genau dieses Verhalten: Striping profitiert stark von einer größeren E / A-Größe.

Nun sollte klar sein, dass das Kombinieren der beiden RAID-Level in einem RAID10-Array nicht zu einer linearen Leistungsskalierung führt, sondern eine Obergrenze dafür festlegt . Ich bin mir ziemlich sicher, dass Sie, wenn Sie mehrere dd / bonnie ++ - Instanzen ausführen (oder die E / A- fioWarteschlange direkt manipulieren), Ergebnisse erzielen, die Ihren ursprünglichen Erwartungen besser entsprechen, einfach weil Sie Ihr E / A-Array vollständiger besteuern ( mehrere herausragende sequentielle / zufällige E / A-Anforderungen), anstatt sie nur von einzelnen sequentiellen E / A-Anforderungen zu laden.