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

你可能感兴趣的:(Ceph)