使用 iozone 和 dd 在 AWS 上對 GlusterFS 和 NFS 進行基準測試會得出不同的結果

我嘗試使用 m1.medium 大小的 EC2 實例在 Amazon Web Services (AWS) 上對 GlusterFS 與 NFS 進行基準測試。我們使用 AWS EBS 作為塊儲存，帶有 XFS 文件系統。使用標準包執行 Ubuntu 12.04。

我使用 iozone 和 dd 進行基準測試。我意識到這些無法與基準測試工具相提並論，但我得到了一些奇怪的結果。

我以 MB/s 為單位的結果如下（所有測試都在客戶端上執行）：

using: iozone -c -e -i 0 -+n -r 64k -s 1000M -t 2

Direct to EBS     GlusterFS     NFS       GlusterFS + NFS
37.5              26.8          99.8      21.1

.

using: dd if=/srv/test of=/dev/null bs=64k count=16k

Direct to EBS     GlusterFS     NFS       GlusterFS + NFS
97.0              40.8          58.3      23.8

直接到 EBS 使用 dd 做得很好，但使用 iozone 它實際上比 NFS 慢。為什麼？

一般來說，我看到 GlusterFS 通常比 NFS 慢 1.5 到 2 倍。這些數字對於 GlusterFS 來說是否現實？

像所有基準一樣，很難將蘋果與蘋果進行比較。似乎會iozone破壞系統並且不會模擬特定的負載。 dd只是測量吞吐量。

我遇到了filebench。您可以模擬特定類型的負載，它將這些不同的測試稱為“filebench個性”。這給了我更現實的數字。我模擬了一個通常是只讀的網路伺服器。儘管filebench在模擬中添加了一個日誌附加，但在這種情況下我刪除了它。我得到以下結果：

以 MB/s 為單位的結果

using: sudo filebench (webserver personality without simulation of log append)
Direct to EBS     GlusterFS     NFS       GlusterFS + NFS
24.2              6.0           17.0      20.4

注意：filebench是 EBS 測試中的約束，因為它在測試期間佔用了 100% 的 CPU。我認為 EBS 結果會更高。

注意 2：當我包含日誌附加測試時，GlusterFS 本身俱有非常高的延遲。這可以在這篇文章中解釋。我沒有調查這個高延遲問題，因為我們預計主要是讀取。

引用自：https://serverfault.com/questions/556128