##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%以上的提升。