cephrgw lifecycle理解

最新推荐文章于 2024-09-27 21:44:00 发布

yueyingshaqiu01

最新推荐文章于 2024-09-27 21:44:00 发布

阅读量429

点赞数 4

分类专栏：开源系统运营优化文章标签： ceph

本文链接：https://blog.csdn.net/yueyingshaqiu01/article/details/140544423

版权

开源系统运营优化专栏收录该内容

22 篇文章 0 订阅

订阅专栏

每个rgw实例有rgw_lc_max_worker个worker (默认为3)来做lifecycle

RGWLC::LCWorker::entry()
	-> RGWLC::process() // 1天只执行1次，(如果rgw_lc_debug_interval>0，只要超过了该时间，就视为没有执行过，会继续执行)
		-> l.lock_exclusive()
		-> cls_rgw_lc_get_head() // 获取对象head，拿到marker
		-> cls_rgw_lc_get_entry() // 获取当前omap entry的状态
		-> cls_rgw_lc_get_next_entry() // 获取下一个omap entry
		-> cls_rgw_lc_set_entry() // 设置entry 状态
		-> cls_rgw_lc_put_head() // 设置head的marker
		-> l.unlock()
		-> bucket_lc_process() // 处理lifecycle 任务
			-> ol.get_obj() // 会借助LCObjLister去list objects, 然后将符合条件的bucket包装成对应的LCOpRule放入workpool，进而有worker来处理
			-> op_rule.process() // worker会调用注册的process函数，LCOpRule::process调用LCOpAction->process对于当前版本过期删实际会调用LCOpAction_CurrentExpiration::process()
				-> remove_expired_obj() 
					-> del_op.delete_obj() // 实际会抽象一个删除cephrgw object的类RGWRados::Object::Delete完成对象的删除流程，因为对象的删除是一个多阶段的流程,里面会涉及标记对象状态，同时将对象记录到default.rgw.log中的gc.x对象队列中
						-> store->set_olh() // 处理.rgw.buckets.index 的状态
							-> bucket_index_link_olh() // 更新.rgw.buckets.index中对象索引的状态，确保业务不可见
		-> bucket_lc_post()

如果是空查每次有1写3读，耗时约4ms，每个worker大概的IO流程是：
1，lock_exclusive 写lc.x，获取lock，成功（这个不知道算写还是算读？看代码是WriteOP）
2，cls_rgw_lc_get_head 获取对象的head，成功
3，cls_rgw_lc_get_entry 获取entry，成功，但是为empty
4，unlock （这个算写还是读？）

如果是有任务，但是已在进行中，每次有1写3读，耗时约4ms，每个worker大概的IO流程是：
1，lock_exclusive 写lc.x，获取lock，成功
2，cls_rgw_lc_get_head 获取对象的head，成功
3，cls_rgw_lc_get_entry 获取entry，因为entry的状态是processing
4，unlock

如果lc.x有bucket任务，而且没有人执行过这个，大概4写2读，每个worker大概的IO流程是：
1，lock_exclusive 写lc.x，获取lock，成功
2，cls_rgw_lc_get_head 获取对象的head，成功
3，cls_rgw_lc_get_entry 获取entry，成功
4，cls_rgw_lc_set_entry 设置为processing，成功
5，cls_rgw_lc_put_head 设置marker，成功
6，bucket_lc_process 开始处理bucket
7，unlock