1 问题描述
创新互联建站是一家集网站建设,嘉禾企业网站建设,嘉禾品牌网站建设,网站定制,嘉禾网站建设报价,网络营销,网络优化,
嘉禾网站推广为一体的创新建站企业，帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿，时刻以成就客户成长自我，坚持不断学习、思考、沉淀、净化自己，让我们为更多的企业打造出实用型网站。
在ceph12和ceph14.2.8使用过程中遇到，当osd数量很多时（1000多个），pg需要设置很多（5、6万）时，ceph balancer status 或 ceph osd status等mgr命令会卡住很长时间才返回，其它mon等命令没问题。
2 问题排查
卡住的都是mgr相关命令，因此推测是mgr进程问题。
排查是osd多，还是pg多导致，这个很容易操作不详细介绍，通过实验是pg多导致的。下图是我的测试环境的ceph：
使用top -H命令可以发现mgr-fin线程cpu使用率经常达到100%。
使用ceph daemon mgr.ceph-212 perf dump查看mgr统计信息 
mgr-fin线程cpu使用率经常达到100%，finisher队列数据量很大，队列又是mgr-fin一个线程在处理，mgr命令发给mgr后就进入finisher队列排队处理，导致mgr命令卡住。
Mgr参数说明：
"mgr_stats_period": "5" 默认为5秒，每5秒所有osd、mds和其它mgr会给主mgr发送一个MSG_MGR_REPORT消息，所有osd给主mgr发送MSG_PGSTATS消息
"mgr_tick_period": "2" mgr每隔2秒给mon发送beacon
“mgr_mon_messages” mgr-mon限流大值，默认为128
Mon参数说明：
"mon_mgr_digest_period": "5" 默认为5秒，每隔5秒，mon会给主mgr发送MSG_MGR_DIGEST
3 mgr介绍
mgr模块分担和扩展monitor的部分功能，减轻monitor的负担。入口在src/ceph_mgr.cc的main函数。
所有mgr服务启动时身份都是standby（初始化一个MgrStandby类对象），初始化一个monitor的客户端monc（MonClient类），调用monc.sub_want函数向monitor请求mgrmap（MSG_MGR_MAP消息）及相关msg。
在MgrStandby::ms_dispatch函数中处理收到的消息，既MgrStandby::handle_mgr_map函数处理MSG_MGR_MAP消息，发现自己在mgrmap为active时，会初始化mgr主服务进程，然后调用Mgr::background_init -->finisher.start()启动Finisher的线程 -->调用finisher.queue向Finisher的队列里添加任务，此任务为Mgr::init()，MgrStandby::send_beacon()。
Mgr::init函数
DaemonServer::init 初始化daemonServer:
初始化了一个mgr类型的Messenger msgr，监听有关mgr消息，收到消息后通过DaemonServer::ms_dispatch处理此消息，包括MSG_PGSTATS、MSG_MGR_REPORT、MSG_MGR_OPEN、MSG_MGR_CLOSE和MSG_COMMAND。
Mgr::load_all_metadata
向monitor节点发请求分别获取mds、osd和mon的元数据，然后根据这些元数据信息生成3个（分别记录mds、osd和mon的元数据）DaemonState的share_ptr添加到daemon_state中。
通过monc->sub_want函数向monitor发消息，分别获取log-info、mgrdigest、fsmap 、servicemap和osdmap。Mgr::ms_dispatch函数处理收到的消息，包括MSG_MGR_DIGEST、CEPH_MSG_MON_MAP、CEPH_MSG_FS_MAP、CEPH_MSG_OSD_MAP、MSG_SERVICE_MAP和MSG_LOG。
py_module_registry->active_start:
这个py_module_registry（PyModuleRegistry类对象）是在mgr服务启动时初始化一个MgrStandby类对象时初始化，然后初始化Mgr类时传进来。MgrStandby::init时调用py_module_registry.init函数（既PyModuleRegistry类的init）加载pyModule：
参数mgr_module_path的值（默认为/usr/share/ceph/mgr/）下所有目录中下面有文件module.py的目录的名字为pyModule的名字（源码中是src/pybing/mgr下的python模块）。为所有的这些pyModule生成类PyModule对象，调用mod->load加载modules，然后添加进modules中。
active_modules.reset(new ActivePyModules(...)) 重新初始化active_modules。
for (const auto &i : modules){
active_modules->start_one(i.second)
}
ActivePyModules::start_one:
modules[name].reset(new ActivePyModule(py_module, clog));
finisher.queue(new FunctionContext([this, active_module, name](int) {
int r = active_module->load(this);
active_module->thread.create(active_module->get_thread_name());
}
处理MSG_MGR_DIGEST消息： （默认每隔5秒，mon会给主mgr发送MSG_MGR_DIGEST）
Mgr::ms_dispatch函数里检查到消息类型是MSG_MGR_DIGEST时调用Mgr::handle_mgr_digest函数
cluster_state.load_digest(m) 从m中提取数cluster_state.health_json，
cluster_state.mon_status_json。
py_module_registry->notify_all("mon_status", "");
py_module_registry->notify_all("health", "");
py_module_registry->notify_all("pg_summary", "");
PyModuleRegistry::notify_all(const std::string ¬ify_type, const std::string ¬ify_id)
active_modules->notify_all函数 既ActivePyModules::notify_all
遍历modules中的ActivePyModule，创建一个任务添加到finisher队列里，此任务调
用ActivePyModule::notify：
调用pyModule的（源码中是src/pybing/mgr下的python模块下的module.py）的
notify函数
src/pybing/mgr/progress/module.py中的notify函数
当notify_type 是"osd_map"时，调用self._osdmap_changed检查是否有osd out了或有新osd加入。
旧的osd out，就调用self._osd_out查找被out的这个osd影响的pg，然后生成一个PgRecoveryEvent对象ev，self._events[ev.id] = ev
新osd加入，就调用self._osd_in检查self._events中是否有PgRecoveryEvent事件ev并且加入的osd在ev.evacuating_osds中，如果有，则结束此ev。
当notify_type 是"pg_summary"时：
data = self.get("pg_dump") 调用ceph_state_get函数 -->self->py_modules->get_python("pg_dump")，即ActivePyModules::get_python获取pg_map格式化后返回，当pg数量很多时，pg_map就会很大，获取pg_map并格式化比较耗时（当pg数量达到6万多时，我统计了下可达到5秒）。但是下面只有当字典self._events不为空时才有可能处理获取的pg_map数据，因此这一步很多时候是多余的，因此可以先判断self._events不为空时才获取pg_map，可以减轻mgr进程的压力。默认每隔5秒，mon会给主mgr发送MSG_MGR_DIGEST，mgr收到后，会执行到这里处理，因此这里很可能就是pg多时，mgr卡住的一个原因。
//这里的self._events中有两类event：PgRecoveryEvent和RemoteEvent。PgRecoveryEvent是正在进行的pg recovery事件（由前面的self._osd_out创建），RemoteEvent由update函数创建
for ev_id, ev in self._events.items(): //更新self._events
if isinstance(ev, PgRecoveryEvent):
ev.pg_update(data, self.log)
self.maybe_complete(ev)
src/pybing/mgr/progress/module.py中的update函数
如果self._events中有ev_id，则ev = self._events[ev_id]，否则ev =RemoteEvent(ev_id, ev_msg, refs)，self._events[ev_id] = ev。
ev.set_progress(ev_progress)
ev._refresh()
4 解决问题
根据上面mgr的介绍和分析，pg多时，mgr卡住的一个原因可能是因为src/pybing/mgr/progress/module.py中的notify函数处理"pg_summary"时没有检查self._events是否为空，就调用self.get("pg_dump")获取并格式化pg_map，比较耗时，finisher队列是mgr-fin一个线程在处理,这里耗时太多，就导致finisher队列里数据来不及处理导致堆积。
因此可以在调用self.get("pg_dump")时，先检查self._events是否为空，如果为空就直接退出notify函数。
经过验证，加入此判断后，重启mgr，运行一段时间后，使用ceph daemon mgr.ceph-212 perf dump查看mgr统计信息： 
查看mgr命令耗时：
可知，finisher队列数据量很小，mgr命令也可以很快返回，问题解决。
当然也可以直接升级ceph到14.2.22。
你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧
分享名称：cephmgr命令卡住-创新互联
链接URL：
http://cdkjz.cn/article/dcjcoj.html
