Ceph 性能調優

介紹

Ceph是一個 Linux PB 級分布式文件系統。一個讓ceph強大的原因就是ceph提供了一系列的可調整的選項。你可以控制ceph管道中的多少數據以及多少操作被緩存。你可以定制不同的清除策略， 或者更改文件存儲操作的線程數。不利的一面是，要深入研究可能有點嚇人，甚至讓人不知道如何下手。在Inktank我們得到了很多關于這些選項如何影響性 能的問題。答案往往是視情況而定。不同的硬件和軟件配置將有利于不同Ceph選項。為了讓人們知道什么東西可能值得看,我們決定過一遍一些最有可能會對性 能產生影響的選項。本文中,使用磁盤JBOD配置時，我們將看到不同的ceph參數。

因為Inktank是愿意支付我畫網絡漫畫(嗨伙計們!)，我看到的一切就相當于下面這幅畫。

在我們繼續之前，如果你不是很很熟悉ceph的配置，這是關于ceph的配置文檔。 一旦你對此有所了解，你要查看的可調參數在這里： here。 

系統設置

我們將使用SAS2208 控制器進行這個測試。這支持JBOD，多重RAID0，單RAID0配置。不幸的是不同的控制器上的表現也不同,所以這些結果可能并不代表其他控制器。希望他們至少會提供一個初始的起點,或許想類似的配置如何執行。

硬件配置包括:

• Chassis: Supermicro 4U 36-drive SC847A

• Motherboard: Supermicro X9DRH-7F

• Disk Controller: On-board SAS2208

• CPUS: 2 X Intel XEON E5-2630L (2.0GHz, 6-core)

• RAM: 8 X 4GB Supermicro ECC Registered DDR1333 (32GB total)

• Disks: 8 X 7200RPM Seagate Constellation ES 1TB Enterprise SATA

• NIC: Intel X520-DA2 10GBE

軟件配置：

• OS: Ubuntu 12.04

• Kernel: 3.6.3 from Ceph’s GitBuilder archive

• Tools: blktrace, collectl, perf

• Ceph: Ceph “next” branch from just before the 0.56 bobtail release.

測試設置

寫了一個python工具來讀取YAML配置文件，以及根據不同的參數設置自動生成ceph.conf配置文件。然后我們使用基準測試工具對每個配置文件進行測試。一些參數配置將被組合在一起以減少總的測試數量。以下YAML文件片段展示了不同的設置。

類似于以前的文章,我們運行測試直接在SC847a使用本機t TCP套接字連接。我們在每塊磁盤的起始部分設置10G的日志分區。本文章只對 SAS2208的JBOD模式進行測試，這種模式不使用主板緩存。其他模式可能在后面的文章進行測試。CFQ用作所有測試IO調度器。

我們使用的是Ceph的可靠的內置基準測試命令:“RADOS bench” 來生成結果。（我今后將寫一篇用smalliobench來測試的文章）。rados bench 有一定的好處有缺點。一方面它將明確地顯示不同大小的對象讀寫速度。但它并不顯示小IO大對象執行的速度有多快。出于這個原因,這些結果并不一定反映 RBD如何最終執行。

類似之前的文章，我們將執行8個并發的 RADOS bench來合并結果，以確保這不是一個瓶頸。我們讓每個RADOS bench 實例分別往自己的pool寫2048個pg。這樣做是為了確保后面的測試實例讀取到獨一無二的對象，而不是之前讀取的對象的緩存。您可能還注意到,我們使 用的每個池的PG數量是2的整數冪個。由于Ceph的方式實現PG分裂行為,有一個2的整數冪的后衛(尤其是在低PG計數!)可以改善數據均勻分布在 osd。在較大的PG計數這可能不是那么重要。

RADOS bench給你一些靈活性的運行設置，對于對象應該是多大,有多少并發,測試應該運行多久。我們已經選定了5分鐘測試使用下面的排列:

• 4KB Objects, 16 Concurrent Operations (2 per rados bench instance)

• 4KB Objects, 256 Concurrent Operations (32 per rados bench instance)

• 128KB Objects, 16 Concurrent Operations (2 per rados bench instance)

• 128KB Objects, 256 Concurrent Operations (32 per rados bench instance)

• 4M Objects, 16 Concurrent Operations (2 per rados bench instance)

• 4M Objects, 256 Concurrent Operations (32 per rados bench instance)

對于每種組合，我們運行相同的測試分別在 BTRFS, XFS, 或者 EXT4的osd 文件系統上。每次測試都會重新格式化文件系統以及重新運行mkcephfs以確保個先前的測試碎片不會影響后面的測試結果。請記住,試圖使用這些結果來判 斷一個ceph集群是如何執行將是一個誤導。每個文件系統在不同的階段可能運行的機制完全不同。盡管如此,每個測試重新格式化文件系統是必要的,以確保不 同的測試之間比較公平。每個文件系統的格式化命令和掛載選項如下:

• mkfs.btfs options: -l 16k -n 16k

• btrfs mount options: -o noatime

• mkfs.xfs options: -f -i size=2048

• xfs mount options: -o inode64,noatime

• mkfs.ext4 options:

• ext4 mount options: -o noatime,user_xattr

在測試期間,collectl用于記錄各種系統的性能統計數據。

4KB RADOS BENCH 寫入測試結果

好吧,希望這個圖表展示是不言而喻的,但如果不是,基本上這里的想法是,我們有3個樣品為每個文件系統,大量的不同的參數,我們畫一個彩色圈表示性能高于 或低于默認配置。可能這里最需要注意的是當 filestore flusher 顯示啟用的時候，BTRFS和XFS的性能變低。除此之外，看起來是授權 journal_aio_true 性能提升最為明顯。

就像16個并發操作的結果一樣，當啟用filestore flusher 的時候BTRFS和XFS性能變低。授權 Journal AIO依然性能提升最為明顯。在256個并發操作的情況下，我們可以看到，增加并發操作可以提升性能，減少并發數統一會降低性能。

4KB RADOS BENCH 讀取測試結果

在這里啟用 flusher 的性能依然表現不佳，這明顯地降低了XFS和EXT4文件系統的讀取性能。禁用調試看起來和增加并發線程操作數一樣對提升性能有幫助。

這一點上，我們非常確定，啟用flusher對小IO讀取性能一點幫助都沒有。禁用調試看起來依然有積極作用，這可能對大量的小IO操作生產的大量 消息日志處理很有幫助。有趣的是增加并發操作數似乎降低了EXT4文件系統的性能，否則我們就可以得出一個規律，越多的并發操作數，性能越高。還要注意有 多少不同的參數似乎在這些結果增加XFS的性能。我有一種感覺，默認的配置對XFS文件系統來說，性能是最好配置性能和最差配置性能的平均水平。

128KB RADOS BENCH 寫入測試結果

默認情況下,filestore flusher只是支持操作大于64 k。通過顯式禁用它,我們看到BTRFS不錯的性能提升,但對XFS相反的效果。授權Journal AIO再次提升了性能。

在這種情況下禁用flusher給EXT4的性能提升。更有趣的是，多所有的IO大小操作都顯示地禁用flusher會降低性能，盡管我們在做128k的操作。journal AIO再次提高性能,有少數增加或減少性能的其他選項。

128KB RADOS BENCH 讀取測試結果

又有一些不同的選項,可以提供一些性能改進(看似BTRFS),但最明顯的影響讀取性能似乎是OSD 操作線程的數量就像在4 k閱讀測試中的一樣。

我們再次看到“默認”配置的情況下,性能很低。在這種情況下,也許有點偏高(即很多其他事物看起來低)。已經說過,OSD OP線程的數量又似乎有一個非常明顯的效果。

4MB RADOS BENCH 寫人測試結果

看了禁用flusher和授權 journal AIO 再次提升了寫人性能。

跟之前的寫入測試結果相比，這次結果很怪異!禁用flusher并不能提升性能,啟用它也不能提升性能。啟用Journal AIO降低了BTRFS的性能。限制緩存和隊列中允許的數據大小也降低了性能。對BTRFS來說，提高這個數量去降低了性能。不知道如果我們每個測試有 100個樣本會不會更好一些。

4MB RADOS BENCH 讀取測試結果

啊哈!更意想不到的結果！看起來OSD 操作線程數量仍然產生了影響,但對于XFS和EXT4性能是隨著線程的數量增加而降低。看起來像禁用消息中的CRC32C也可以提升性能。

最后有并發讀取操作,我們再次看到,OSD OP線程數量的增加傷害EXT4和XFS的性能。對于BTRFS,看起來與4個 OSD 操作線程數達到高性能峰值。

測試結果概要

上面所示的散點圖給我們一個不同的參數對于不同的輸入輸出大小如何影響性能相的印象，但沒有給出具體每個參數是如何影響性能的答案。讓我們分別看看 每個參數。接下來的圖表中，每個參數的測試樣本的平均值和標準差是根據默認配置的平均值和標準差計算和對比得出的，僅顯示評價值之間的百分比差異。如果結 果的標準偏差范圍重疊,不做顏色。如果標準偏差范圍不重疊和參數平均值較高,結果是在綠色的顏色。如果范圍不重疊和參數平均水平較低,顏色紅。

這看起來EXT4通過增加允許不同的隊列和緩沖區的字節數定義在我們的“大字節”測試中性能可以得到提升。已經說過,似乎大量并發操作時,始終只對EXT4性能提升有效。

在大量小IO操作的情況下，增加隊列允許的操作數是明顯有效提升性能的。有一個相當明顯的例外是對于EXT4的讀取。通過單獨地測試每個組，我們可以隔離其他的影響因素，保持測試的有效性。

禁用調試似乎和小IO操作性能有好處,尤其是對讀取性能。這有可能是OSD操作并發數的影響，所以值得試試更少的操作并發數的情況，看看結果怎么樣。

有趣的是，將文件存儲操作線程數從默認的2變為1時，對中小數據的操作性能提升有積極作用。這有可能是因為我們在每個osd的磁盤使用了JBOD配置。

增加filestore op線程的數量從2到4可能提供了一個輕微的改善,但整體表現似乎是大致相同的。

filestore op線程的數量從2增加到8然而似乎會導致一些性能回歸

看來講 XATTRS 放在文件系統中還不如將它放在底層數據庫更能提升性能。對于XFS來說這也許有點快，但這些結果可能不夠精確地說明。

默認情況下，filestore flusher 是被啟用的，但僅允許64kb或者更大的數據操作才生效。當我們顯示地關閉flusher的時候，居然對EXT4文件系統下256線程的4k數據寫操作影 響那么大，這是很奇怪的，我懷疑這是EXT4文件系統測試結果的誤差。在較大的輸入輸出大小,結果好壞參半。看來著對BTRFS是比較有意義的，起碼完全 脫離了flusher的影響。

顯式地啟用flusher幾乎普遍性不利于小操作,除了4 k數據對 EXT4文件系統寫入。如果你有讀過我們的文章：Argonaut vs Bobtail Performance Preview ，我們注意到小EXT4讀取性能有所改善,而EXT4寫性能退化。Argonaut版本默認對所有的寫操作開啟flusher，而Bobtail版本改為對64k及以上的操作才開啟。看來如果你使用EXT4，你當前只能選擇快速地讀寫小文件。

journal AIO似乎能提升所有的寫入操作性能,除了大量的并發大IOs。我們將考慮在ceph的后續版本作為默認選項。

8 個 osd的主機和12個2.0 ghz Xeon E5核心,禁用CRC32c計算在信使不削一顧。我們不可能綁定CPU。在兩種情況下,它似乎有所不同,我要擔風險,說我們沒有足夠的樣品。

這里的結果似乎相當沒有說服力。我想我們又需要更多的樣品。

再次,結果似乎相當沒有說服力,雖然也許希望。OSD磁盤線程的數量增加到4可能有正面的影響。

8個OSD磁盤線程,看起來可能會有一些負面影響,除了一個積極的。我們可能需要更多的樣本。

減少OSD op線程的數量從默認的2 到1是普遍不利于性能除了幾個特定的場景。如果使用EXT4和做很多大讀取操作，看起來像它可能提供一個溫和的性能提升。

我們之前有說過這個，但反思一下，將osd 操作線程數從2提高到4，似乎是錯的。提高osd操作線程數性能顯著提升，除了EXT4和XFS下的大數據讀取是性能降低的。

進一步增加osd 操作線程數，結果有好有壞。

鑒于我們通常是可疑的關于256個并發4 k XFS讀取的結果,減少隊列中允許的字節數的性能不好,尤其是大的IOs。令人驚訝的是,減少這些值不會導致更大的降低性能。

最后,減少隊列操作數肯定會導致性能下降。當256線程讀取的時候我們又看到了一個疑似異常。對于大的IO看來是某個地方存在瓶頸。

結論

雖然在這個實驗我們看起來得到了一些結果，但是我想重申，每個測試我們只有三個樣本，這樣對于辨認細微的性能差異是不具有說服力的，還可能存在一些偏差。除此之外,很可能不同的硬件和軟件配置將顯示不同的結果。所以要以適當的粗粒度來看待這些結果。

可以說從這個實驗我們學習到了ceph的一下特性。也就是說flusher不值得使用（當然有一些例外），jouranl AIO 是值得使用的，OSD操作數也有積極的作用。也許還有許多其他的地方我們需要隔離性能。這將是有趣的測試修改filestore同步間隔,并改變子目錄合 并和分裂行為。我希望這篇文章是有用的,它可以為人們提供一個調整自己的Ceph部署的起點。