☰

使用 ZFS 記錄大小 16k 而不是 128k 的缺點

tag-icon • tag-icon zfs qemu performance-tuning
使用 ZFS 記錄大小 16k 而不是 128k 的缺點

我在專用伺服器上使用 Proxmox。對於生產，我仍在使用 ext4，但我決定開始使用 ZFS。

因此，我建立了兩個具有不同記錄大小的獨立 ZFS 儲存池：

  • 除 MySQL/InnoDB 之外的所有內容均為 128k
  • MySQL/InnoDB 為 16k（因為 16k 是我使用的預設 InnoDB 頁面大小）

我添加了 16k 池來檢查它是否真的對 MySQL/InnoDB 資料庫效能產生影響。確實如此。我每秒的交易量增加了大約 40%，延遲降低了 25%（我已經使用系統基準和TPCC）。

出於實際原因，目前我更願意使用一個具有 16k 記錄大小的大池，而不是兩個單獨的部分（16k 和 128k）。我知道，我可以在單一 ZFS 池上建立子磁碟區並為它們提供不同的記錄大小，但這也是我想避免的。我更喜歡透過 Proxmox GUI 進行管理。

我的問題：

  1. 如果我開始對所有內容使用較小的 (16k) 記錄大小而不是 128k（Proxmox 上的預設值），我會遇到哪些缺點？

  2. QEMU 磁碟映像是否具有與 innodb_page_size 等效的值？如果是的話 - 它的尺寸是多少？

    我嘗試用​​以下方法檢查qemu-img info：

     $ qemu-img info vm-100-disk-0.raw
 image: vm-100-disk-0.raw
 file format: raw
 virtual size: 4 GiB (4294967296 bytes)
 disk size: 672 MiB

伺服器使用情況是：

  • www/php 的容器（大量小文件，但在容器磁碟文件內）
  • java/spring應用程式的容器（它們產生大量日誌）
  • mysql/innodb 資料庫的容器（無需解釋）
  • 本機備份/復原操作，包括壓縮備份
  • 處理大型 gzip 檔案（不是每天，低優先順序）

答案1

簡短回答：這實際上取決於您的預期用例。作為一般規則，預設的 128K 記錄大小是機械磁碟的好選擇（其中存取延遲主要由尋道時間 + 旋轉延遲決定）。對於全 SSD 池，我可能會使用 16K 或最多 32K（前提是後者能夠顯著提高資料的壓縮效率）。

長答案：對於 HDD 池，我建議堅持使用預設的資料集 128K 記錄大小，並為 zvol 使用 128K volblocksize。理由是 7.2K RPM HDD 的訪問延遲主要由尋道時間決定，這並不影響不是使用記錄大小/卷塊大小進行縮放。讓我們做一些數學計算：7.2K HDD 的平均尋道時間為 8.3ms，而讀取 128K 區塊只需要約 1ms。因此，命令頭部尋道（8ms+延遲）來讀取小的 16K 區塊似乎很浪費，特別是考慮到對於較小的讀取/寫入，您仍然受到 r/m/w 延遲的影響。此外，較小的記錄大小意味著較大的元資料開銷和較差的壓縮。因此，雖然InnoDB 發出16K IO，並且對於專用資料集，可以使用16K 記錄大小來避免r/m/w 和寫入放大，但對於混合用途資料集（即：不僅用於資料庫本身，還用於更通用的資料集）工作負載）我建議保持在 128K，特別是考慮到小記錄大小的壓縮影響。

然而，對於 SSD 池，我會使用更小的 volblocksize/recordsize，可能在 16-32K 範圍內。理由是 SSD 的訪問時間要短得多，但耐用性有限，因此為較小的寫入寫入完整的 128K 塊似乎過多。此外，大記錄大小所要求的 IO 頻寬放大在高 IOPS 設備（如現代 SSD）上更令人擔憂（即：您可能面臨頻寬飽和的風險）前達到 IOP 限制）。

答案2

我建議調整如果以及何時你遇到問題了。

ZFS 預設為 128K 記錄大小，這對於大多數配置和應用程式來說是可接受且有效的。

例外情況包括：

  • 某些資料庫應用程式；較小的值可能是合適的。
    代價是壓縮的效率會降低，這可能比更高的交易計數對效能產生更大的影響！
  • 大量媒體工作負載（例如影片編輯）；較大的值很有用
  • 正常 ZFS 用例之外的特定工作負載

如果您覺得資料庫基準測試的效能在一定記錄大小下更好，請使用它！
但你有沒有用現實的方式測試過非標竿管理工作量以確保您做出正確的調整？

答案3

就其價值而言，建議根據 zfs 文件本身設定「recordsize=16K」。

https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Workload%20Tuning.html#innodb

編輯：我剛剛在 proxmox 伺服器上更改此設置不到 12 小時後恢復了此設置，該虛擬伺服器具有相當大的資料庫（> 60GB 資料）。伺服器在分析數據方面嚴重落後。事實上'z_rd_int_' 進程從較低的 CPU 使用率躍升至每個 5% 左右，而 'z_wr_int_' 處理後的 CPU 使用率下降 - 可能是因為處理的資料較少。

然而，將雜湊演算法更改為 edonr ( zfs set checksum=edonr vmpool) 確實產生了積極的影響：perf top不再顯示SHA256TransformBlocks為頂級內核函數。

因此，該建議似乎並不在所有情況下都很好 - 它可以恢復到原始設定。

相關內容