Warum verbringt mein ZFS-Pool 97% seiner Zeit mit dem Lesen des Ziels und nur etwa 3% mit einem Schreibvorgang?

Das verblüfft mich und ich kenne keinen Weg, um herauszufinden, was ZFS tatsächlich tut.

Ich verwende eine saubere Installation von FreeNAS 11.1 mit einem schnellen ZFS-Pool (importierte Spiegel auf schnellen 7200s) sowie eine einzige UFS-SSD zum Testen. Config ist so ziemlich "out of the box".

Die SSD enthält 4 Dateien der Größen 16 bis 120 GB, die mit der Konsole in den Pool kopiert wurden. Der Pool ist entlastet (lohnt sich: 4x Einsparung, 12 TB Größe auf der Festplatte) und das System verfügt über viel RAM (128 GB ECC) und schnelles Xeon. Der Speicher ist ausreichend - zdbder Pool verfügt über insgesamt 121 MB Blöcke (544 Bytes auf der Festplatte, jeweils 175 Bytes im RAM), so dass die gesamte DDT nur etwa 20,3 GB beträgt (etwa 1,7 GB pro TB Daten).

Wenn ich die Dateien in den Pool kopiere, sehe ich Folgendes zpool iostat:

Es macht einen Zyklus von bis zu einer Minute von Low-Level-Reads und einem kurzen Satz von Schreibvorgängen. Der gelesene Teil ist im Bild dargestellt. Die Gesamtschreibgeschwindigkeit für die Aufgabe ist auch nicht groß - der Pool ist zu 45% / 10 TB leer und kann nativ mit ca. 300 - 500 MB / s schreiben.

Ohne zu wissen, wie zu prüfen ist, besteht der Verdacht, dass die niedrigen Lesevorgänge vom Lesen der DDT und anderer Metadaten stammen, da sie nicht in ARC vorinstalliert sind (oder kontinuierlich von den ARC durch geschriebene Dateidaten herausgeschoben werden). Könnte sein.

Vielleicht findet es Dup-Ups, also gibt es nicht viel zu schreiben, nur erinnere ich mich nicht an irgendwelche Dup-Versionen dieser Dateien und es tut dasselbe von / dev / random, wie ich es mir gut erinnere (ich werde das überprüfen und in Kürze aktualisieren). Könnte sein. Keine wirkliche Idee.

Was kann ich tun, um herauszufinden, was genauer ist, um es zu optimieren?

Update auf RAM und Dedup:

Ich habe das Q aktualisiert, um die DDT-Größe nach dem ersten Kommentar anzuzeigen. Dedup-RAM wird häufig mit 5 GB pro TB x 4 angegeben. Dies basiert jedoch auf einem Beispiel, das für die Deduplizierung nicht geeignet ist. Sie müssen die Blockanzahl multipliziert mit Bytes pro Eintrag berechnen. Das "x 4", das oft zitiert wird, ist nur ein "weiches" Standardlimit (standardmäßig begrenzt ZFS die Metadaten auf 25% von ARC, es sei denn, es soll mehr verwendet werden. Dieses System ist für Deduplizierung vorgesehen und ich habe 64 GB hinzugefügt, was alles zur Beschleunigung ist Metadaten-Caching).

In diesem Pool zdbbestätigt sich also, dass die gesamte DDT nur 1,7 GB pro TB und nicht 5 GB pro TB (20 G insgesamt) benötigen sollte, und ich bin froh, Metadaten 70% von ARC und nicht 25% (80 G von 123 G) zu geben.

Bei dieser Größe sollte es nicht notwendig sein, etwas anderes als "tote" Dateiinhalte aus ARC auszuwerfen . Ich bin also auf der Suche nach ZFS, um herauszufinden, was es denkt, dass es vorgeht, und ich kann die Auswirkungen meiner Änderungen sehen, da ich wirklich sehr überrascht bin, was die Menge an "Low-Level-Lesevorgängen" angeht eine Möglichkeit, die Realität dessen, was sie glaubt, zu untersuchen und zu bestätigen.