為什麼在我的 ZFS NAS 上進行大量刪除、複製、移動會阻塞所有其他 IO？
我有一個基於 Solaris 11 ZFS 的 NAS 設備，帶有 12x1TB 7.2k rpm SATA 驅動器，採用鏡像配置。
它從同一個池中提供 2 個服務 - 一個用於小型 VM 場的 NFS 伺服器和一個用於小型團隊託管共享文件的 CIFS 伺服器。cifs ZFS 已啟用去重，而 NFS ZFS 文件系統已去重。壓縮無處不在。我每天都在對每個文件系統進行快照，並保留最後 14 個快照。
如果我在直接通過 SSH 連接到 NAS 時移動、複製或刪除大量數據，我會遇到性能問題。基本上，該程序似乎會阻止所有其他 IO 操作，甚至會因為收到磁碟超時而導致 VM 停止。
關於為什麼會出現這種情況，我有一些理論，但希望能對我下一步可能做的事情有所了解。
任何一個：
1）硬體不夠好。我對此不太相信——該系統是具有 30GB RAM 的 HP X1600（單 Xeon CPU）。雖然這些驅動器只有 7.2k SATA，但它們每個的最大 IOPS 應該是 80，這對我來說應該綽綽有餘了。不過很高興被證明是錯誤的。
2）我配置錯了——很有可能。是否值得在任何地方關閉重複數據刪除？我的工作假設 RAM = 有利於重複數據刪除，因此給它一個合理的 RAM 空間。
- Solaris 在調度 IO 方面很愚蠢。本地命令是否有可能
rm完全阻止對 nfsd 的 IO？如果是這樣，我該如何改變？
選項#2 很可能是原因。當 dedup 表 (DDT) 完全適合記憶體時，Dedup 的性能最佳。如果沒有，那麼它會溢出到磁碟上，並且必須進入磁碟的 DDT 查找非常慢並且會產生阻塞行為。
我認為 30G 的 RAM 已經足夠了，但 DDT 的大小直接取決於要重複數據刪除的數據量以及重複數據刪除對數據的效果如何。dedup 屬性是在數據集級別設置的，但查找是在整個池中完成的，因此只有一個池範圍的 DDT。
有關計算 DDT 大小的資訊，請參閱此 zfs-discuss 執行緒。本質上，它是池中每個唯一塊的一個 DDT 條目，因此，如果您有大量數據但重複數據刪除率較低，則意味著更多唯一塊，因此 DDT 更大。系統嘗試將 DDT 保留在 RAM 中，但如果應用程序需要記憶體，則其中一些可能會被清除。擁有 L2ARC 記憶體有助於防止 DDT 進入主池磁碟，因為它將被從主記憶體 (ARC) 驅逐到 L2ARC。