##CEPH Mimic版本 - Bluestore io過程、延遲分析及優化建議##
Ceph bluestore與filestore相比較， 除了bluestore不需要寫journal，就IO過程（流程）來講大體上是類似的，OSD側的io流程、過程調用分析網絡上已經有很多文章了，在這裏就不再展開，我將過程貼到下方：
寫流程：
讀流程:
我們來看看Bluestore中寫IO狀態遷移：
在Bluestore::queue_transactions方法中會創建事務上下文TransContext並初始化（設置開始時間-start、初始狀態-STATE_PREPARE)，然後執行經由OSD層封裝的transaction，接着調用_txc_state_proc提交io以及metadata，最後返回應答。
需要注意的是：bluestore中通過配置*_deferred_*參數來控制io的行爲，默認情況下io size=32KB及以下，進行的是deferred io，而aio與deferred io的過程有些區別,請看如下圖表：
基本狀態遷移圖如下：
STATE_PREPARE
|
|
STATE_AIO_WAIT
|
|
STATE_IO_DONE
|
|
STATE_KV_QUEUED
|
|
STATE_KV_SUBMITTED
|
|
STATE_KV_DONE ————————— STATE_DEFERRED_QUEUED
| |
| |
|__________________ STATE_DEFERRED_CLEANUP
|
|
STATE_FINISHING
|
|
STATE_DONE
通過 ceph --admin-daemon {*.asok} osd perf dump 可以查看每個OSD運行時各階段的延遲；此外，perf加上火焰圖也是分析延遲的好工具，當然要解決問題，最終都離不開對代碼細節的把握。
STATE_PREPARE：該階段主要是io前的準備工作，如：分配磁盤空間等；根據io size的大小同步執行aio或者延遲io；如果是延遲io的metadata和data會先寫入rocksdb、後面再延遲更新到OSD block設備上；如果是aio就更新狀態爲STATE_AIO_WAIT，並提交io；該階段延遲由bluestore_state_prepare_lat標識。
STATE_AIO_WAIT：如果是aio，等待aio完成（aio完成後，bluestore回調aio_cb）, 更新狀態爲STATE_IO_DONE；很顯然，deferred io是不需要等待aio的，所以通過上述osd perf dump看到的延遲通常都極小；該階段延遲由bluestore_state_aio_wait_lat標識，其延遲受配置、設備性能等的影響。
STATE_IO_DONE： 結束io，將狀態設置爲STATE_KV_QUEUED，通知kv_sync線程同步io及metadata；該階段的延遲也通常很小，延遲由bluestore_state_io_done_lat標識。
STATE_KV_QUEUED： 在kv_sync中flush OSD block設備、提交kv transaction，將設置狀態爲KV_SUMMITTED, 如果是deferred io，還會進行kv的清理操作；通知kv_finalize完成線程執行後續的io收尾工作；該階段延遲由bluestore_state_kv_queued_lat標識，其延遲受設備性能、rocksdb等的影響。
STATE_KV_SUBMITTED： 提交回調到bluestore的finisher線程，由bluestore返回應答，將狀態設置爲STATE_KV_DONE；該階段延遲由bluestore_state_kv_committing_lat標識。
STATE_KV_DONE：如果是aio，將狀態設置爲STATE_FINISHING, 否則設置爲STATE_DEFERRED_QUEUED；該階段延遲由bluestore_state_kv_done_lat標識
STATE_FINISHING：清理操作，如果滿足條件，也會提交deferred io；該階段延遲由bluestore_state_finishing_lat標識，其延遲通常很小。
STATE_DEFERRED_QUEUED： 延遲io如隊列，等待執行；延遲io也是通過aio的方式提交，延遲io的執行受*_deferred_*配置的影響，該階段的延遲由bluestore_state_deferred_queued_lat標識，其延遲通常也較大。
STATE_DEFERRED_CLEANUP： 延遲io的清理操作，事務上下文等的清理與aio一致，由STATE_FINISHING 過程完成；該階段延遲由bluestore_state_deferred_cleanup_lat標識，其延遲通常都會很大。
根據上述的狀態遷移以及各階段的時間消耗說明，將db和wal放在SSD上，給block加緩存（如：flashcache、bcache、CAS等），將是提升性能的有效手段；從我們的實踐來看，調整配置參數可以提升性能，但提升幅度有限。
由前面所述STATE_KV_SUBMITTED期間的submit_transaction_sync（元數據同步）操作比較耗時[在我們的測試環境中，db，wal放在DC4500 240GB的SSD上（每個SSD承載5個OSD），在單fio numjobs=1，iodepth=32 ，rw=randwrite情況下，sync的操作延遲也達到了0.3ms以上]，如果能夠將sync操作獨立出來、與其他的一些狀態並行處理，將會有不錯的性能提升效果[Ceph Mimic版本中有一個debug參數 - bluestore_debug_omit_kv_commit,該參數開啓後，性能得到明顯提升，但是生產環境該參數是不能使用的，因在異常重啓情況下，會出現數據不一致]
如果研發實力足夠的話，有興趣的讀者可以考慮下面的優化方式： kv_sync/kv_finalize多線程化、自定義wal（自維護wal，而不是rocksdb）、採用async read io；這幾個點產品化，相信性能，與社區版本相比至少得30%以上的提升。