ZFS最佳實踐指南

時間 2019-11-09

標籤 zfs 最佳實踐指南简体版

原文原文鏈接

ZFS最佳實踐指南

（注：本文目前的寫做背景是Solaris 10 以及 OpenSolaris，但一樣對FreeBSD具備參考做用，php

原文請參見：http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide）
其它參考：
- Ubuntu上使用ZFS（Zettabyte File System）
- 提高ZFS性能的10個簡便方法
性能測試
- Ubuntu測試-使用phoronix-test-suite
- 六款優秀的 Linux 基準測試工具

1 ZFS管理事項

1.1 ZFS存儲池建議

本節描述了配置ZFS存儲池的通用建議。html

1.1.1 系統

請使用64位內核運行ZFS。mysql

1.1.1.1 內存與交換空間

推薦使用1GB以上的內存。ios
裝載每一個ZFS文件系統約耗費64KB的內存空間。在一個存在上千個ZFS文件系統的系統上，咱們建議您爲包括快照在內的每1000個所裝載的文件系統多分配1GB額外內存。並對爲其所帶來的更長的引導時間有所準備。sql
由於ZFS在內核保留內存中緩存數據，因此內核的大小極可能會比使用其它文件系統時要大。您能夠配置額外的基於磁盤的交換空間（Swap Space）來解決系統內存限制的這一問題。您可使用物理內存的大小做爲額外所需的交換空間的大小的上限。但不管如何，您都應該監控交換空間的使用狀況來肯定是否交換正在進行。數據庫
如條件容許，請不要將交換空間與ZFS文件系統所使用分區（slice）放在同一磁盤上。保證交換區域同ZFS文件系統分開。最佳策略是提供足夠多的內存使您的系統不常使用交換設備。緩存
更多的內存使用事項，請見：內存與動態重構（Dynamic Reconfiguration）建議。安全

1.1.2 存儲池

如條件容許，架設每一個系統的存儲池請使用整個磁盤。性能優化
對於生產系統，考慮使用整個磁盤而不是分區（slice），有以下理由：服務器
- 容許ZFS開啓磁盤的寫緩存。但若是您使用有永久性寫緩存的磁盤陣列，那麼這一問題並不突出，做爲虛擬設備的分區也能夠受益於盤陣的寫緩存。
- 若在分區上包含有ZFS和UFS文件系統，則對待替換壞盤的恢復步驟則變得更加複雜。
- 若在其餘分區上還含有UFS文件系統，則ZFS存儲池（和其下的磁盤），使用zpool import和export功能不易被遷移至他處。
- 通常而言，維護分區會增長管理成本。應經過簡化您的存儲池結構來下降管理成本。

對於全部生產環境，請配置ZFS以便其能夠修復數據不一致問題。使用ZFS的冗餘技術，如raidz，raidz2，鏡像，或者副本>1，不須要考慮在其下的存儲設備上的RAID級別的實現。應用此類冗餘技術，其下的存儲設備到主機鏈接的故障均可以被ZFS發現並修復。
請不要用48個設備來建立一個raidz，raidz2或者鏡像配置的邏輯設備。請參見後面的冗餘配置的示例。
在建立複製的存儲池配置中，請使用多個控制器達到了減小硬件故障和提升性能的做用，例如：

# zpool create tank mirror c1t0d0 c2t0d0

配置熱備來加速硬件故障時的恢復速度。對於高數據損失平均時間（Mean Time To Data Loss，MTTDL ，譯者注）的環境來講熱備是相當重要的。例：

# zpool create tank mirror c1t0d0 c2t0d0 spare c1t1d0 c2t1d0

請按期運行zpool scrub來肯定數據完整性問題。若您的驅動器是消費級質量的驅動器，則請考慮將scrub的進度以周爲單位進行；如果數據中心級質量的驅動器，則請考慮以月爲單位。
對模擬磁盤驅動器（SSD）的電子存儲設備，ZFS也能夠工做得很好。因爲每字節成本相對較高，您可在這類存儲池上開啓壓縮屬性。

1.1.2.1 簡單的或條帶化的存儲池限制

簡單的或條帶化的存儲池有一些應被考慮的限制。

可經過兩種方式實現對存儲空間的擴充：
- 添加另外一磁盤以擴展條帶（stripe）。這也會提高存儲池的性能，由於更多的設備能夠被併發使用。注意：當前的ZFS實現是，一旦添加，虛擬設備則不能被移除。

# zpool add tank c2t2d0

用更大的虛擬設備替代現有的虛擬設備

# zpool replace tank c0t2d0 c2t2d0

ZFS能允許多種設備故障。
- 對於簡單的存儲池來講，元數據（metadata）是雙重冗餘的，但數據並不冗餘。
- 您可使用ZFS copies屬性爲數據設定冗餘級別。
- 若文件塊不能被徹底讀取且沒有冗餘，ZFS會告訴您哪些文件受其影響。

對於簡單存儲池而言，替換故障硬盤既須要訪問舊有設備也須要訪問新設備，這是爲了可以將舊數據放到新設備上。

# zpool replace tank c0t2d0         ### 錯誤：不能再建立數據由於不存在冗餘

# zpool replace tank c0t2d0 c2t2d0  ### ok

1.1.3 多個存儲池於同一系統

在ZFS存儲池中的資源容許不一樣的文件系統在不一樣的時候受益於全部資源。這一策略可大幅提升在存儲池內的任一文件系統性能。
若一些做業量須要更多的可預測的性能特色，那麼您可考慮將做業量分給不一樣的存儲池。
例如，Oracle日誌記錄器性能很是依賴於I/O響應時間，咱們能夠經過將這樣的負載保持於一個單獨的有最低響應時間的小存儲池來實現。

1.1.3 根存儲池建議

若您正在使用ZFS根文件系統（root file system），請保持根存儲池（即存儲池的數據集是被分配給根文件系統的）與用於數據的存儲池分開。關於這一策略存在幾個理由：

在您不會想要放到數據存儲池的根存儲池上存在一些限制（與數據池相比，根存儲池存在一些限制）。鏡像存儲池與單磁盤存儲池是支持的。可是，RAID-Z或有一塊磁盤以上的非複製存儲池不行。（注：在 FreeBSD 上，若是不使用 ZFS 引導系統，而只是用它做爲根文件系統，則沒有這種限制）
數據存儲池能夠是體系結構無關的。這對在SPARC和Intel之間移動數據存儲池是有好處的。根存儲池是很是依賴於特定的體系結構的。
一般，咱們認爲將系統的「個性」同其數據分開是個不錯的主意。這樣的話，您就能夠改變一個而不用改變其餘的。

給咱們當前分配的做爲單獨的文件系統（例如：根，/usr和/var）配置不一樣的存儲池根本不合理。這或許都不是一個所支持的配置。對於這些目錄有單獨的數據集卻是可能，但只能在同一個存儲池中。關於ZFS和SVM鏡像的根內容，請參見UFS/SVM節。

1.2 存儲池性能事項

1.2.1 通用存儲池性能事項

爲了更佳的性能，請使用單個磁盤或至少只是由少數盤組成的LUN。經過使ZFS於LUN的設置中更可見，ZFS可以提供更佳的I/O調度決策。
依賴於做業量，當前的ZFS的實現相比於其餘的基於分頁的文件系統能夠不時的使更多I/O被請求。若是吞吐量正在流向存儲，由iostat來觀察，其已接近存儲和主機之間的信道鏈路的容量，調小zfs recordsize屬性通常能提升性能。這種調整是動態的，但只是對新文件建立有影響。已存在的文件仍是保持其原有的recordsize。
調節recordsize對順序類型的負載沒有幫助。調節recordsize的方式是針對使用隨機少許的讀寫來密集的處理大文件的狀況來提高做業量。
請參考ZFS與數據庫建議
當前，存儲池的性能可能會由於存儲池很滿且文件系統被頻繁的更新而降低，如繁忙的郵件服務器。在這些狀況下，請保持存儲池的空間在80%如下以維持存儲池性能。

1.2.1.1 單獨日誌設備

ZFS intent log（ZIL，ZFS意圖日誌）符合POSIX的同步事務（synchronous transactions）的要求。例如，數據庫從系統調用返回時經常須要其事務要在穩定的存儲設備上。在默認狀況下，intent log從主存儲池中分配塊。然而，若使用獨立的intent log設備，其可能會得到更佳的性能，像NVRAM或專用磁盤。請肯定是否一個單獨的日誌設備適合您的環境：

實現單獨的日誌設備（log device）所體現的任何性能提高都依賴於設備類型、存儲池的硬件配置、和應用的做業量。
日誌設備能夠是不復制或鏡像的，但RAIDZ不被日誌設備所支持。
日誌設備的最小的尺寸同存儲池中的最小設備尺寸相同，也是64MB。存儲於日誌設備上的實際數據量可能相對較少。當日志事務（系統調用）被提交時，日誌塊被釋放。
最大的日誌設備的尺寸應大概是物理內存的1/2，由於那是能被保存的實際數據的最大量。例如，若是一個有16GB物理內存的系統，其最大的日誌設備應是8G。
對於日誌設置信息和日誌性能信息，請參見以下Blog：slog_blog_or_blogging_on來查看關於單獨日誌設備的總說明，參見《Solaris ZFS管理指南》（《Solaris ZFS Administration Guide》）。

1.2.1.2 內存與動態重構（Dynamic Reconfiguration）建議

ZFS的自適應置換高速緩存（Adaptive Replacement Cache，ARC）試圖使用最多的系統可用內存來緩存文件系統數據。默認是使用除了1GB以上的全部的物理內存。當內存壓迫性增加時，ARC會放棄內存。請在以下情形時考慮限制最大ARC內存的使用範圍：

當有已知數量的內存老是被應用程序請求時。數據庫經常屬於這一類。
在支持內存板動態重構的平臺上，以防止ZFS將漸大的內核佔據到全部的內存板上。
請求大內存分頁的系統也會受益於對ZFS緩存的限制，這可將大的分頁分解爲基本分頁。
最後，若系統上還運行有其餘非ZFS文件系統，除了ZFS以外，最好再留一些空閒內存給那些文件系統做爲緩存。

這些限制內存使用範圍的方式被認爲會使ARC不能緩存更多的文件系統數據，這可能會對性能有所影響。總之，若內存既沒被ZFS使用也沒被其餘系統組件使用，限制ARC則是浪費資源的。注意非ZFS文件系統一般仍會設法使用系統的空閒內存來緩存數據。調節ARC的詳細信息，請參考以下段落： http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#Limiting_the_ARC_Cache

1.2.2 RAID-Z配置要求及建議

一個以N塊X大小和P個奇偶校驗磁盤的RAID-Z配置能夠擁有大約（N-P）×X的字節並能承受P個設備故障而不破壞數據完整性。

配置單奇偶校驗的RAID-Z須要3塊磁盤起（2+1）。
配置雙奇偶校驗的RAID-Z2須要4塊硬盤起（2+2）。
配置三奇偶校驗的RAID-Z3須要6塊起（3+3）。
推薦的每組磁盤數在3至9之間。若是您有更多的磁盤，請使用多個組。

有都市傳說認爲 ZFS 應配置爲 (N+P），其中N爲2的整數次方冪而P爲與對應 RAID-Z/RAID-Z2/RAID-Z3 的奇偶校驗盤數量，而且對性能影響很大。這種說法是沒有科學根據的。

1.2.3 鏡像配置建議

在設備數上沒有可實際影響的限制
在SUN Fire X4500服務器上，請勿用48個設備建立一個鏡像。請考慮建立24個兩兩設備的鏡像。這一配置將磁盤容量縮小了1/2，但多至24個磁盤或每個鏡像上1個磁盤均可以無端障的被失去。
若您須要更佳的數據保護，三路鏡像可在MTTDL上比雙路鏡像有顯著提高。但再升爲四路（或更高的）鏡像，則只是在數據保護上提供有限的改進。因此若三路鏡像還不夠，請考慮其餘的數據保護方式。

1.2.3 我應該配置RAID-Z、RAID-Z2仍是鏡像存儲池？

一般須要考慮的是您的目標是最大磁盤空間仍是最優性能

RAID-Z配置可得到最大磁盤空間，且當被寫入和讀取大塊（large chunk）（128KB或更大）的數據時一般都表現不錯。
RAID-Z2配置提供了卓越的數據可用性且其具有同RAID-Z類似的特色。相比於RAID-Z或雙路鏡像，RAID-Z2具備顯著更佳的數據損失平均時間（MTTDL）。
鏡像配置消耗更多的磁盤空間，但一般其具有更好的隨機少許的讀取能力。
若是您的I/O是大量的、順序的、或是寫頻繁的，則ZFS的I/O調度器會將其聚集起來，以這樣一種方式您會得到很高效的磁盤使用而不論數據的複製模型。

爲得到更好的性能，在大量的、不可緩存的、隨機讀取負載上，鏡像配置要顯著的勝於RAID-Z配置。關於RAIDZ所需注意事項的更多信息，請參考以下blog： WHEN TO (AND NOT TO) USE RAID-Z

1.2.4 RAID-Z配置舉例

例如在Tunmper上的RAID-Z配置，將c3t0和c3t4（磁盤0和1）鏡像做爲您的根存儲池，剩下的46塊可用磁盤用於用戶數據。以下的raidz2配置舉例說明了如何配置剩下的46塊盤：

5×(7+2)，1個熱備，17.5 TB
4×(9+2)，2個熱備，18.0 TB
6×(5+2)，4個熱備，15.0 TB

1.3 ZFS遷移事項

1.3.1 ZFS與分區技術（Zone）

當在安裝有區域（zone）的Solaris系統上使用ZFS數據集（dataset）時請牢記以下幾點：

當前您還不能給區域關聯ZFS快照。
在Solaris 10發行版中對於全局區域（global zone）的根路徑（root path）或非全局區域（non-global zone）請不要使用ZFS文件系統。
您能夠在Solaris Express發行版中使用ZFS做爲區域的根路徑，但請牢記修補或升級這些區域是不被支持的。

想要了解區域使用ZFS的更多信息，請參見以下FAQ條目： [1]（http://opensolaris.org/os/community/zones/faq/#cfg_zfsboot）

1.3.2 UFS/SVM

當下，您不能在當前的Solaris 10發行版中使用ZFS爲根文件系統。若是您想使用基於鏡像備份的根文件系統，您須要使用SVM將包含系統軟件（root，/usr，/var，等等）的分區（slice）進行鏡像。其餘全部存儲均可以使用ZFS來進行管理。請不要使用ZFS和SVM重疊存儲。例如，您可使用磁盤或分區做爲SVM卷或者ZFS存儲池的一部分。但請不要在相同的磁盤或者分區上使用SVM和ZFS配置。當將數據從UFS文件系統遷移至ZFS文件系統時，請參考以下實踐：

取消共享（unshare）現有的UFS文件系統
從以前的掛載點（mount points）取消掛載現有的UFS文件系統
掛載UFS文件系統至臨時非共享掛載點
互起rsync實例，遷移UFS數據至ZFS文件系統
在新的ZFS文件系統上設置掛載點和sharenfs屬性

1.3.2.1 UFS/SVM 交互

ZFS 能夠不須要任何額外的卷管理軟件即能很好工做。若是您須要額外級別的卷管理，ZFS要求能將連續的1至4MB的邏輯塊映射至連續的物理塊上。若能夠達到這一要求，咱們就能以ZFS的功能使用捲了。

1.3.3 VxVM/FS

2 常規ZFS管理信息

ZFS只管理在線數據。
關於配置存儲池的更多信息，請參見，ZFS存儲池建議。
ZFS文件系統當被建立時便被自動掛載。
ZFS 文件系統不須要經過修改/etc/vfstab被掛載。
當前，ZFS不提供像ufsdump和ufsrestore命令這樣的全面的備份/恢復工具。然而您可使用zfs send和 zfs receive命令來捕獲ZFS數據流。您也可使用ufsrestore命令來恢復UFS數據至ZFS文件系統。
更多的ZFS管理任務，請參看zfs.1m和zpool.1m聯機手冊。更詳細的文檔，請參考《Solaris ZFS管理指南》（《Solaris ZFS Administration Guide》）。詢問ZFS問題，請加入opensolaris/zfs討論組。

3 應用服務器使用ZFS事項

3.1 ZFS NFS 服務器實踐

請參考以下課程所述之UFS至ZFS遷移經驗：

存在用戶主目錄（home directory）被重命名但其併爲被取消掛載。當新的主目錄也被共享時，NFS卻繼續服務於舊主目錄。
切勿混淆UFS的目錄與在一樣文件系統層面上的ZFS文件系統，這會搞亂管理和維護。
切勿混淆基於NFS原始共享的ZFS文件系統（NFS legacy shared ZFS file systems）與基於ZFS的NFS共享的文件系統（ZFS NFS shared file systems），由於這樣的模型很難以維護。請使用基於ZFS的NFS共享的文件系統（譯者注，即便用ZFS自帶的sharenfs方式而不要使用NFS本身的通用的原始共享方式）。
ZFS能夠由sharenfs文件系統屬性與zfs share命令共享。例如：

# zfs set sharenfs=on export/home

該語法自動共享文件系統。若ZFS文件系統須要被共享，請使用zfs share命令。例如：

# zfs share export/home

關於跨NFS的ZFS的性能信息，請參閱ZFS與NFS服務器性能。

3.1.1 基於ZFS的NFS服務器優點

NFSv4風格的ACL（訪問控制列表）在ZFS文件系統上可用且ACL信息可自動經過NFS可用。
ZFS快照能夠經過NFSv4可用，這樣掛載主目錄的NFS就能夠訪問其.snapshot目錄了。

3.2 ZFS主目錄服務器實踐

當規劃您的ZFS主目錄（home directory）時，請參考以下實踐：

每一個用戶配置一個文件系統
使用磁盤配額和保留以管理用戶磁盤空間
使用快照備份用戶主目錄

當從UFS文件系統向ZFS文件系統遷移數據時，請參考以下實踐：

取消（Unshare）現有UFS文件系統的共享
從以前的掛載點（mount points）取消掛載現有的UFS文件系統
掛載UFS文件系統至臨時非共享掛載點
互起rsync實例，遷移UFS數據至ZFS文件系統
在新的ZFS文件系統上設置掛載點和sharenfs屬性

請參閱 #ZFS_NFS_Server_Practices section for additional tips on sharing ZFS home directories over NFS.

3.2.1 ZFS主目錄服務器的好處

得益於ZFS的高容量架構，可使其可以處理許多小文件與許多用戶。
用戶主目錄（home directory）的額外空間能夠經過添加更多的設備到存儲池而輕鬆擴大。
ZFS磁盤配額是一種便捷的管理主目錄空間的方式。
使用ZFS inheritance屬性可將屬性應用於許多文件系統。

3.3 ZFS郵件/新聞服務器

3.4 ZFS軟件開發服務器

3.5 ZFS備份還原建議

3.5.1 使用ZFS快照

可使用ZFS快照做爲備份用戶主目錄的快速便捷方式。例如，以下語法會建立在/tank/home中的全部主目錄的遞歸的快照。

# zfs snapshot -r tank/home@monday

您能夠建立滾動快照用來管理快照副本。要了解更多信息，請參考Blog：Rolling Snapshots Made Easy。
您可使用zfs send和zfs receive命令存檔快照至更持久的存儲上。
您能夠建立增量快照流（請看「zfs send -i」語法）。
zfs send 和 receive命令不是企業級備份解決方案。

3.5.2 使用ZFS於AVS

Sun StorageTek Availability Suite（AVS），是一套Solaris的基於主機的數據服務，其同Veritas VVR（Volume Replicator）和Flashsnap（point-in-time copy，時間點副本）產品相似，當前在Solaris Express發行版中可用。 SNDR（Sun StorEdge Network Data Replicator）同ZFS send和recv功能不一樣，其具有的是固定時間（time-fixed）的複製功能。例如，您能夠得到一時間點快照，複製它，或是基於先前快照的差異進行復制。AVS II與SNDR功能的結合，還容許您進行固定時間複製。其餘模式的AVS SNDR複製功能容許您得到CDP（Continuous Data Replication，持續數據複製）。ZFS當前並無這類功能。關於AVS的更多信息，請參見OpenSolaris AVS項目。請在此查看AVS/ZFS演示。

3.5.3 使用ZFS於企業備份解決方案

Sun StorEdge Enterprise Backup Software（Legato Networker 7.3.2）產品可全面備份和恢復包括ACL的ZFS文件。
Symantec NetBackup 6.5產品可徹底備份與恢復ZFS文件，包括ACL，雖然其兼容性矩陣（Compatibility Matrix）（2007年9月）很意外的沒有說起ZFS。
IBM的TSM產品也可被用於備份ZFS文件。可是具體的支持性不是很是清晰。基於TSM支持的文檔在IBM的站點，ZFS的ACL可被TSM client 5.3支持。已被確認（SUN內部）可在5.4.1.2上正常工做。

tsm> q file /opt/SUNWexplo/output # Last Incr Date Type File Space Name — ————– —- —————

1   08/13/07   09:18:03   ZFS     /opt/SUNWexplo/output
                           ^
                           |__正確的文件系統類型

ZFS快照能夠在有快照的文件系統中經過.zfs目錄訪問。請配置您的備份產品跳過這些目錄。

關於ZFS的企業級備份解決方案問題的最新信息，請參見ZFS FAQ 爲了能充分利用ZFS的功能，如快照，來提升備份和還原的進度，ndmp服務會在Solaris（首先在OpenSolaris）中發行。根據這些附加功能，企業級備份解決方案能夠經過充分利用快照來提高對大存儲庫的數據保護。

3.6 ZFS與數據庫建議

關於正在進行的ZFS和數據庫性能測試的信息，請參看zfs_and_databases。還可參見ZFS for Databases

概要說明

若是數據庫針對I/O使用固定磁盤的塊或記錄尺寸，請將ZFS的recordsize屬性設成與數據庫一致。您能夠在每一個文件系統上作這一操做，即便是共享一個存儲池的多個文件系統。
因爲其copy-on-write設計，調小ZFS的recordsize是一種以犧牲批處理報告查詢爲代價而提升OLTP（On-Line Transaction Processing，聯機事務處理）性能的方式。
ZFS校驗存於磁盤上的每一個塊（block）。這減輕了數據庫層面上對校驗數據的須要和額外的時間。若校驗由ZFS代替了數據庫的，全部的差別均可以在數據返回給應用程序以前被捕獲和修正。ZFS在數據庫上的性能是很是快的活動目標。保持對Solaris發行版的更新很是重要。

截至2007年7月，以下功能會對數據庫性能產生影響：

ZFS 放出多至35個併發I/O至每一個頂級設備，且這能夠致使服務的時間延長。
ZFS對每一輸入塊進行一些多至64K的低級預取操做，這樣作可令存儲帶寬飽和。詳情請參見6437054號Bug以及這篇blog。
使用8K的預取並用5到10個併發I/O來幫助一些數據庫的負載。對於調節這些值的作法請參看ZFS Evil Tuning Guide。這種調節須要有望在將來發行版中去除。

Oracle事項

爲獲得更好的OLTP性能，請將ZFS的recordsize同Oracle的db_block_size相匹配。
請在混合的批處理和OLTP中關注批處理報告
對Oracle日誌請以默認的128K記錄尺寸使用單獨的文件系統。
在SXCE Build 68發行版中，您能夠爲ZFS intent log（ZIL）使用單獨的設備建立ZFS存儲池。更多信息，請參見separate intent log。請不要將ZFS intent log設備同Oracle日誌相混淆。
最小化Oracle日誌響應時間，以期在整個事務過程當中只是惟一的I/O，這每每是咱們所但願的。就SAN存儲陣列而言，Oracle日誌響應時間應是接近寫至SAN緩存的響應時間的，所以沒有必要在數據空間和日誌空間中來劃分主軸（spindle）資源：單一的存儲池操做。但對於在JBOD存儲上的Oracle來講，其已被看到使用被分出來的一套主軸（不受制於讀或寫的競爭）能夠有助於日誌的響應時間。這反過來能夠對一些工做量有幫助，如這類在存儲級別上有高寫讀比的操做。

PostgreSQL

限定ZFS ARC已在內存與動態重構（Dynamic Reconfiguration）建議中描述
關於對日誌使用單獨存儲池，請參看上述Oracle事項。
請設置ZFS recordsize=8K（注意：請在任何數據文件的建立以前作這一設置！）
從日誌存儲池中初始化數據庫，以後爲每個數據庫建立一個新的表分區（tablespace）指向數據存儲池

MySQL

參考：A look at MySQL on ZFS

InnoDB:
限定ZFS ARC已在內存與動態重構（Dynamic Reconfiguration）建議中描述
關於對日誌使用單獨存儲池，請參看上述Oracle事項。
請設置ZFS recordsize=8K|16K（注意：請在任何數據文件的建立以前作這一設置！）
以後請對數據和日誌使用不一樣的路徑（在mysql.conf）中設置
MyISAM:
限定ZFS ARC已在內存與動態重構（Dynamic Reconfiguration）建議中描述
請爲日誌（WAL）建立獨立的intent log。若您沒有該功能（即您運行在Solaris 10發行版），那麼請建立至少兩個存儲池，一個存數據，一個存日誌（WAL）
關於對日誌使用單獨存儲池，請參看上述Oracle事項。
請設置ZFS recordsize=8K|16K（注意：請在任何數據文件的建立以前作這一設置！）

請參閱一些在PostgreSQL和MySQL中用db_STRESS性能測試得到的真實結果。

3.7 ZFS與複合存儲事項

某些存儲子系統會將數據暫放在固態內存設備，如存儲陣列上的NVRAM，容許其以很是低的響應時間響應寫操做。這些內存設備一般被認爲是穩定的存儲，在必定意義上其能倖免於掉電或其餘類的崩潰。在關鍵時刻，ZFS是不知道該內存存儲器的持久性的，而且要求該存儲器的數據同步至磁盤。若這些存儲器真的被肯定爲是穩定的，存儲系統應被配置爲忽略這些來自ZFS的請求。

3.8 驅動問題

4 ZFS管理/觀察工具

5 虛擬化事項

5.1 ZFS與虛擬帶庫（VTL）

虛擬帶庫解決方案是經過對模擬磁帶、磁帶驅動器和帶庫的使用而出現的一種硬件與軟件的結合體。虛擬帶庫被用於備份/存檔系統，被定位於用來減小硬件和軟件的成本。虛擬帶庫是大量磁盤空間的吞噬者，咱們相信ZFS將容許其更有效和安全的管理大量的、在線磁盤空間。

Falconstor虛擬帶庫–該虛擬帶庫須要磁盤塊設備來工做。其不使用外部文件系統。所以目前不能使用ZFS和Falconstor虛擬帶庫相結合的方法。
Copan 虛擬帶庫–同上（Copan 使用 Falconstor 虛擬帶庫）。
來自BakBone的NetVault–該備份解決方案包括了虛擬帶庫功能，其已經在運行有ZFS的Thumper上測試過。

5.2 ZFS與VMWare

6 ZFS性能事項

對於基本系統、內存、存儲池和副本建議，請參考以下章節：

ZFS存儲池建議
我應該配置RAID-Z、RAID-Z2仍是鏡像存儲池？
Roch/Jim/Neel的Blog

6.1 ZFS與應用程序事項

6.1.1 ZFS與NFS服務器性能

配有ZFS的NFS，這被應用在許多不一樣地方並未報有明顯不足。不少人報告對性能表示失望，但這恐怕是將跨NFS的ZFS的性能同本地文件系統所比較了。衆所周知相比於本地或直連的文件系統而言，提供NFS服務會明顯下降速度。尤爲是對於低線程併發的做業量而言。有一種危險的建立更優的跨NFS的ZFS的方式，是以犧牲數據完整性爲代價設定內核變量zil_disable。該參數的設定並不被推薦。請參考：ZFS與數據庫建議。關於跨NFS的ZFS性能的更多詳細信息，請參見 zfs and nfs。

Web 服務器
流做業量

6.2 ZFS文件系統的其餘行爲與使用誤區

6.3 DTrace剖分（profile）以分類應用程序

6.4 性能優化

6.5 調節與策略設置

6.6 ZFS更多事項

壓縮
校驗和- 校驗問題已被測量過，約1GHz的CPU能夠校驗500MB/sec的數據。
RAID-Z
截至Solaris 10 11/06發行版時，校驗和，壓縮，和RAID-Z奇偶計算所有出如今線程同步存儲池數據的上下文中。在重負載狀況下，該線程可能成爲性能瓶頸。在將來發行版中全部這類計算有望在併發線程中完成。經過修復了6460622號Bug以後，壓縮問題已再也不是單線程，且會成爲Solaris 10 8/07發行版的一部分。

6.7 可擴展性

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。