Das verwirrt mich und ich weiß nicht, wie ich genauer herausfinden kann, was ZFS tatsächlich macht.
Ich verwende eine Neuinstallation von FreeNAS 11.1 mit einem schnellen ZFS-Pool (importierte Spiegel auf schnellen 7200ern) und einer einzelnen UFS-SSD zum Testen. Die Konfiguration ist praktisch „out of the box“.
Die SSD enthält 4 Dateien mit Größen von 16–120 GB, die mithilfe der Konsole in den Pool kopiert wurden. Der Pool ist dedupliziert (lohnt sich: 4-fache Einsparung, 12 TB Größe auf der Festplatte) und das System verfügt über reichlich RAM (128 GB ECC) und einen schnellen Xeon. Der Speicher ist völlig ausreichend – zdbzeigt, dass der Pool insgesamt 121 M-Blöcke hat (jeweils 544 Bytes auf der Festplatte, jeweils 175 Bytes im RAM), sodass der gesamte DDT nur etwa 20,3 GB groß ist (etwa 1,7 GB pro TB Daten).
Aber wenn ich die Dateien in den Pool kopiere, sehe ich Folgendes zpool iostat:
Es führt einen Zyklus von bis zu einer Minute mit Lesevorgängen auf niedriger Ebene und einem kurzen Schreibschub durch. Der Lesevorgang ist im Bild zu sehen. Die allgemeine Schreibgeschwindigkeit für die Aufgabe ist auch nicht besonders gut – der Pool ist zu 45 %/10 TB leer und kann nativ mit etwa 300 – 500 MB/s schreiben.
Ohne zu wissen, wie man das überprüft, vermute ich, dass die Low-Level-Lesevorgänge vom Lesen des DDT und anderer Metadaten herrühren, da diese nicht in ARC vorgeladen sind (oder durch das Schreiben von Dateidaten kontinuierlich aus ARC herausgeschoben werden). Vielleicht.
Vielleicht findet es Deduplizierungstreffer, sodass nicht viel geschrieben wird, aber ich kann mich nicht an Duplizierungsversionen dieser Dateien erinnern und soweit ich mich erinnere, macht es dasselbe von /dev/random aus (ich werde das in Kürze prüfen und aktualisieren). Vielleicht. Keine wirkliche Idee.
Was kann ich tun, um den Vorgängen genauer auf den Grund zu gehen und sie zu optimieren?
Update zu RAM und Deduplizierung:
Ich habe die Frage aktualisiert, um die DDT-Größe nach dem ersten Kommentar anzuzeigen. Dedup-RAM wird oft mit 5 GB pro TB x 4 angegeben, aber das basiert auf einem Beispiel, das für Dedup nicht wirklich geeignet ist. Sie müssen die Blockanzahl multipliziert mit Bytes pro Eintrag berechnen. Das oft angegebene „x 4“ ist nur eine „weiche“ Standardgrenze (standardmäßig begrenzt ZFS Metadaten auf 25 % von ARC, sofern nicht angegeben wird, mehr zu verwenden – dieses System ist für Dedup ausgelegt und ich habe 64 GB hinzugefügt, wasallekann verwendet werden, um das Zwischenspeichern von Metadaten zu beschleunigen).
Dieser Pool zdbbestätigt also, dass das gesamte DDT nur 1,7 GB pro TB und nicht 5 GB pro TB (insgesamt 20 G) benötigen sollte, und ich bin gerne bereit, den Metadaten 70 % von ARC und nicht 25 % (80 G von 123 G) zuzuweisen.
Bei dieser Größe sollte es nicht ausgeworfen werden müssenirgendetwasaußer „toten“ Dateiinhalten von ARC. Ich möchte ZFS also tatsächlich untersuchen, um herauszufinden, was es denkt, was vor sich geht, und damit ich die Auswirkungen aller Änderungen sehen kann, die ich vornehme, denn ich bin wirklich sehr überrascht über die enorme Menge an „Low-Level-Reads“ und suche nach einer Möglichkeit, die Realität dessen zu untersuchen und zu bestätigen, was es denkt, was es tut.