over 5 years ago

最近想把一些跑在 ubuntu 的服務搬到 btrfs 上,花了點時間實測 btrfs,
紀錄一下測試過程的想法心得和疑問。

為何選 btrfs

雖然 google 一些資料後(憑感覺)發現 zfs 相較之下似乎比較少災情,但考量到幾個點以後還是決定使用 btrfs:
- 官網宣稱有對 SSD 做最佳化,剛好想搬的服務就是跑在 SSD 上。
- 號稱 linux 下一代檔案系統。
- 在處於有 proxy 的網路環境下,ubuntu 裝 btrfs 比較方便。

目的

一開始會想用 btrfs 主要想透過 block 層級的壓縮達到加速 io 的效果
因此下面介紹會侷限在壓縮功能的效能比較,主要會針對三種檔案系統做比較:

  • ext4
  • btrfs
  • btrfs with lzo compression

其他有趣的特點諸如內建的 raid,snapshot,COW(copy on wtite) 等網上已經有很多文章分享了,
本文就不贅述。

測試過程

測試環境

在 macbook air 上裝 virtual box 虛擬 ubuntu 機器來實測,
VM 規格為 1 core 的 CPU, 768m 的記憶體,額外掛載一顆 8g 的 disk 測試。

測試工具

我用 iozone3
因為想要觀察 io 過程中的 cpu 使用狀況,所以找了這個能同時紀錄 cpu 使用狀況的工具。
測試指令為:

iozone -a -R -s 1536m -r 4096k -o -i 0 -i 1 -i 2 -+u -f 測試檔案路徑

參數說明
- -a 自動測試模式
- -R 結果輸出成 ecel 格式
- -s 測試檔案大小 (設為 vm 記憶體兩倍避免 os 的快取誤事)
- -r 每次傳送的 record 大小,依我的理解應該是指檔案系統的 block (設為 4096k 是因為 ext4 和 btrfs 預設的大小即為 4096k )
- -i 測試的類型,0: 循序寫,1: 循序讀,2: 隨機讀寫
- -+u 紀錄 cpu 使用狀況
- -f 指定測試的檔案路徑

測試結果

io 效能


分兩部分來看:
1. ext4 vs btrfs:無論是讀還是寫都表現比 ext4 佳,尤其在讀檔部分。讀檔不能理解,寫檔或許跟 COW 有關?
2. 有加入 lzo 壓縮的 btrfs vs btrfs:在寫檔部分有加入 lzo 壓縮選項的 btrfs 效能大增,但讀取部分則略減,似乎解壓縮花的時間比壓縮多?

cpu 使用率


一樣分兩部分看:

  1. ext4 vs btrfs:寫入時 CPU 使用率是 btrfs 較高,讀取時則差異不大,莫非 COW 比較吃 CPU?
  2. 有加入 lzo 壓縮的 btrfs vs btrfs:出乎意料的寫入時有壓縮的 btrfs CPU 使用率竟然較低?個人推測或許 iozone 測試 io 時產生的暫存檔在用 lzo 的壓縮率極高,導致 os 不用花多少力氣寫檔。

不管如何,更快的寫入速度以及更低的 CPU 使用率一直讓我直覺上不能接受。
因此我開始猜測,會不會 btrfs 對 SSD 有做優化的關係呢?
畢竟 btrfs 官網說 mount 時加入 SSD 選項會對寫入做一些優化,避免頻繁寫入導致 SSD 效能衰退。

btrfs on HDD

為了確認是不是因為在 mount btrfs 加入 ssd 選項所以產生出乎意料的結果,我找了一台普通硬碟的機器,用 KVM 開 ubuntu 測試。

io

cpu


其實這比較符合我一開的預測,畢竟 lzo 宣稱是快速解壓縮的演算法,利用 lzo 壓縮主要提升的應該會是讀取速度才對(而且 cpu 使用率也相對較高),但是在寫入部分依舊是高 io 效能和低 CPU 使用率,只是相較於在 SSD 下就沒那麼誇張。
雖然依舊難以解釋,但至少是勉強可以接受的範圍就是了...

沒有結論的結論

上面的實驗數據僅供參考,畢竟環境變數太多了。主要是想紀錄測試 io 過程的一些想法心得和疑問,希望有朝一日能豁然開朗。

題外話,一開始的目的是想要透過檔案壓縮達到加速 solr 讀索引的時間,但測到一半發現 lzo 對 solr 底層的索引檔案壓縮率不到 5% ....orz

← 基於 swarm + consul + nginx 達到 HA 和 dynamic scaling 的架構 swarm + interlock + nginx + redis 達到保有 session 的 HA 及 dynamic scaling 架構 →