cephFS kernel client IO性能瓶頸分析
【版權聲明】非商業用途在註明作者及本公眾號的前提下無需授權即可轉載
1、導言
本文通過測試數據的對比分析cephfs kernel client 性能瓶頸，方法：使用fio多線程測試，通過grafana分析。
FIO命令：
#fio -filename=tstfile10G -size=50G -thread -group_reporting -numjobs=8-direct=1 -ioengine=libaio -bs=4M -rw=write -iodepth=64 -iodepth_batch_submit=8-iodepth_batch_complete=8 -name=write_64k_64q
write_64k_64q: (g=0): rw=write, bs=4M-4M/4M-4M/4M-4M, ioengine=libaio,iodepth=64
**查看osd的latency，還有點疑惑，需要分析：**
上述中所取點的值看出:
`op_w_latency = 83`
`op_w_process_latency = 80`
`op_subop_w_latency = 56`
`journal_latency = 44`
問題：`op_w_process_latency`和`journal_latency`相差36ms，耗費在哪裡了？,這裡只從源碼角度分析，暫不考慮打log的內容。
採用cephFS的 kernel client 在 同步單線程 DIRECT 寫的場景下，性能測試出來的數據表現不是很令人如意，本文基於內核linux-4.11.3，從cephfs kernel client的IO 路徑進行代碼分析定位問題。
2、流程分析
2.1 序列圖
2.2 Client端
00321當client端發起IO後需要先 ceph_open 發起ceph_mdsc_do_request 到 MDS server端獲取文件的元數據，然後返回給client端。
01684 當client 端發起 寫時 vfs_write 的寫函數對應到 cephfs 是 ceph_write_iter
01277 ceph_write_iter 先鎖住一個inode ，inode_lock 是一個信號量鎖，該鎖是為了保證IO數據的一致性所做的互斥，對性能損耗較大。
01321 ceph_get_caps ,client端發起一個到MDS端讀caps 獲取XATTR的動作，如果本地已經有caps的緩存，則從本地取，不然發請求去MDS取
01335 添加spin_lock 鎖，鎖住 snap 的 context 操作，對於 direct IO 每次IO都會跑run一次這個鎖，這裡對性能影響也較大。
01346 解開 spin_lock鎖，解鎖snap 的context 操作
01351 判斷是 DIRECT 的寫 調用 ceph_direct_read_write
01354不是 direct 的寫 調用 ceph_sync_write
01374非同步寫調用 generic_perform_write
01377 inode_unlock 解鎖
02586獲取 cap 的 reference，當referece>0時，caps 不會被釋放
01394釋放 cap 的reference
02616當session 斷開，需要重新獲取一次 caps
02646 client 端發起一個獲取 attr 的請求 __ceph_do_getattr
02137 如果 force= false，並且 caps 的 mask在租約期限內，無需去mds端再取一次 caps
02148client端發起一個 ceph_mdsc_do_request 請求，到server 獲取每個object的元數據
2.3 Server端
01543handle_client_getattr 發起獲取GETATTR 請求
02772rdlock linklock
02773rdlock authlock
02774rdlock filelock
02775rdlock xattrlock
02777acquire rdlocks,wrlocks,xlocks
02787hit inode
02795返回獲取的xattr 請求 respond_to_request
3、CephFS性能分析小結
cephfskernel client write 一次寫需要做的步驟有：
（1） 一次client 到mds端得open 操作獲取元數據，如果local 已經有 cap的緩存了就本地取
（2） 每個IO，client 端都需要加 inode_lock 信號量鎖；
（3） client 發起讀 MDScaps，如果local 已經有 caps的緩存了就本地取，否則就到MDS 端取，MDS 端加 rdlocksSimpleLock鎖 返回 ATTR
（4） 每個direct io，client端都會run spin_lock鎖一次
（5） client 端發起寫OSD端，server 端寫數據到OSD
（6） client inode_unlock 解信號量鎖cephFS每次IO請求都需要加好幾把鎖，對比RBD，cephfs client 寫多了：
另外 direct IO 下盤，每個OBJECT 是按順序下發再返回，3副本的話需要6次寫才能完成返回，因此性能影響較大。
4、性能問題解決方案
CephFS的性能不如意問題主要是其本身的架構決定的，並且將內核態的cephfs 客戶端改成nfs-ganesha用戶態客戶端性能還有 20%~30%的下降，如果去改這個架構來提升性能，粗略的評估下來是性價比不划算。就ceph目前的架構設計來說，合理的提升性能的思路及方向有：
（1）調整相應的參數，這個效果有點用但是不大；
（2）上DPDK 網卡驅動用戶態化；
（3）將MDS的元數據放在NVDIMM cache或者 SATA/SAS/PCIe/NVMe SSD, 3DXPOINT里
（4）上SPDK 方案
（5）採用 SATA/SAS/PCIe/NVMe SSD, 3DXPOINT存儲數據而不是 SAS盤
（6）增大ceph的規模scale out橫向擴展
（7）將數據3副本改為2副本
TAG:全球大搜羅 |