CEPH Mimic版本 - Bluestore io过程、延迟分析及优化建议

痛定思痛。 2023-03-13 02:47 13阅读 0赞

本文章向大家介绍CEPH Mimic版本 - Bluestore io过程、延迟分析及优化建议，主要包括CEPH Mimic版本 - Bluestore io过程、延迟分析及优化建议使用实例、应用技巧、基本知识点总结和需要注意事项，具有一定的参考价值，需要的朋友可以参考一下。

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