Der Pool besteht aus zwei Festplatten (WD Red 3 TB, 5200 U/min?, max. Übertragungsrate 147 MB/s & Verbatim (Toshiba) 3 TB, 7200 U/min) in der raidz1-0Konfiguration. Er enthält 2,25 TB Daten, die auf zwei Festplatten dupliziert sind, sodass die Gesamtmenge 4,5 TB beträgt. Als ich den Pool erstellt habe, habe ich keinen ashiftWert angegeben.
zpool statuszeigt, dass „scan: scrub am Sonntag, 3. Januar 2021, 13:58:54 Uhr, 0 in 32h43m mit 0 Fehlern repariert hat“. Das bedeutet, dass die Scangeschwindigkeit nur 4.5e6 / (32.717 * 60 * 60) = 38.2 MB / s. betrug. Ich würde mindestens 2 x 100 oder bis zu 2 x 200 MB/s erwarten, obwohl die WD-Platte etwas langsamer ist als die andere.
Die SMART-Daten der Festplatten zeigen, dass alles in Ordnung ist. Sie haben eine Betriebsdauer von 6,5 bis 7 Jahren, aber die Start-Stopp-Zählung beträgt nur etwa 200.
Die Hauptfrage: Was könnte die schlechte Leseleistung erklären?
Merkwürdigerweise zdbzeigte sich, dass der Pool den Pfad verwendet, /dev/disk/by-id/ata-WDC_WD30EFRX-xyz-part1anstatt /dev/disk/by-id/ata-WDC_WD30EFRX-xyz. fdisk -l /dev/disk/by-id/ata-WDC_WD30EFRX-xyzerwähnt, dass „Partition 1 nicht an der physischen Sektorgrenze beginnt“, aber ich habe gelesen, dass dies nur die Schreibleistung beeinträchtigen sollte. Ich könnte versuchen, dies zu beheben, indem ich das Gerät entferne und es mit dem richtigen vollständigen Festplattenpfad wieder hinzufüge, da die Daten dupliziert (und gesichert) sind.
Der Pool hat 7,1 Millionen Dateien. Ich habe die Ausführung sha1sumeiner 14276 MB großen Datei getestet, nachdem ich die Caches geleert hatte. /proc/sys/vm/drop_cachesEs dauerte 2 Minuten und 41 Sekunden, was einer Lesegeschwindigkeit von 88,5 MB/s entspricht.
dd bs=1M count=4096 if=/dev/disk/by-id/ata-WDC_WD30EFRX-xyz of=/dev/nullDie Geschwindigkeit wurde mit 144 MB/s angegeben, bei der Nutzung mit ata-WDC_WD30EFRX-xyz-part1134 MB/s und ata-TOSHIBA_DT01ACA300_xyzmit 195 MB/s.
Auf meinem NAS laufen recht alte Softwareversionen:
$ modinfo zfs
filename: /lib/modules/3.11.0-26-generic/updates/dkms/zfs.ko
version: 0.6.5.4-1~precise
license: CDDL
author: OpenZFS on Linux
description: ZFS
srcversion: 5FC0B558D497732F17F4202
depends: spl,znvpair,zcommon,zunicode,zavl
vermagic: 3.11.0-26-generic SMP mod_unload modversions
Es verfügt über 24 GB RAM, von denen 8 GB für eine JVM reserviert sind, der Rest kann frei verwendet werden. Allerdings scheint nicht viel davon frei zu sein:
$ free -m
total used free shared buffers cached
Mem: 23799 21817 1982 0 273 1159
-/+ buffers/cache: 20384 3415
Swap: 7874 57 7817
Bearbeiten 1:
Ich habe einige Tests mit durchgeführt bonnie++, wobei ich eine einzelne 4 GB große Datei auf dem RAIDZ verwendet habe: Schreiben 75,9 MB/s, Überschreiben 42,2 MB/s und Lesen 199,0 MB/s. Ich gehe davon aus, dass ich die Umrechnung von „Kilo-Zeichen/Sekunde“ richtig vorgenommen habe.
Ah, gerade ist mir aufgefallen, dass das parallele Scrubben genauso lange dauert wie bei der langsamsten Platte mit 5.400 U/min. Es spielt keine Rolle, dass das Scrubben bei 7.200 U/min (möglicherweise) schneller war.
Bearbeiten 2:
Ich habe die Anzahl der Dateien im Pool von 7,1 Millionen auf 4,5 Millionen (-36,6 %) reduziert und die Bereinigungszeit von 32,72 Stunden auf 16,40 Stunden (-49,9 %) gesenkt. Die Datenmenge ist dieselbe, da ich diese kleinen Dateien einfach in ein niedrig komprimiertes ZIP-Paket gepackt habe.
Ich habe auch recordsizevon 128k auf 512k erhöht, keine Ahnung, ob das in diesem Fall einen Unterschied gemacht hat. Andere bereits vorhandene Daten wurden nicht berührt, sodass sie das Original behalten recordsize. Oh, und /sys/module/zfs/parameters/zfs_scan_idlewar auf eingestellt 2.
Antwort1
Welche Version von ZFS verwenden Sie?
Vor 0.8.x werden alle Metadaten und Daten durchsucht, so wie sie auf den Festplatten abgelegt sind. Dies führt zu vielen Suchvorgängen, die die Leistung mechanischer Festplatten beeinträchtigen. Bei Verwendung mit leistungsschwachen 5K-RPM-Festplatten, die mit Millionen kleiner Dateien gefüllt sind, bedeutet dies sehr lange Scrub-/Resilver-Zeiten. Mit diesen älteren ZFS-Versionen können Sie einige ZFS-Tunables anpassen;Zum Beispiel:
echo 0 > /sys/module/zfs/parameters/zfs_resilver_delay
echo 0 > /sys/module/zfs/parameters/zfs_scan_idle
Beachten Sie, dass eine Erhöhung der Scrub-Priorität zu einer langsameren Anwendungsleistung führen würde.
0.8.x verwendet einen Batch-Scrub-Ansatz, bei dem Metadaten in größeren Batches gesammelt und erst dann die relevanten Daten gescannt werden. Dies führt zu viel schnelleren (d. h. halb so langen) Scrubs, ohne dass etwas eingestellt werden muss (die oben genannten Knöpfe sind nicht einmal mehr vorhanden).
Die effektivere Methode zum Erhöhen der Scrub-/Resilver-Geschwindigkeit ist wahrscheinlich die Aktualisierung Ihrer ZFS-Version.