系统相关
首页 > 系统相关> > monitor 内存异常增长问题澄清

monitor 内存异常增长问题澄清

作者:互联网

前言

在ceph-12.2.1版本上monitor内存会随着时间缓慢增加,重庆渝州监狱mon内存频繁增长超过10G,现场暂时有一个规避方案(当内存使用率超过85%,mon进程超过2G时会自动重启),如果频繁重启mon会引发很多不能把控的问题(比如重启mon过程中pg出现一些卡io状态,mon不能及时处理,导致录像丢失)。针对该问题经过两周的问题观察和分析,问题最终得到解决。

问题引发原因:

monitor相关的消息需要beacon(向主mon发送信标,然后主mon会回复应答)机制来确认消息状态,但是有部分类型的消息,主mon收到之后并没有回复应答。导致这些编码后的消息一直收不到回复,一直不能释放。导致消息在内存中持续堆积,最终引发内存暴涨问题。

问题澄清:

这个问题ceph社区开发人员已经讨论过,是一个没有考虑到的bug。解决方法是在一些消息预处理时,直接给消息附加属性no_reply(从routed_requests map中移除该消息的路由请求),这样该消息发送完成后,不会再等待主mon的回复应答,消息发送完成后,保存相关元数据信息后,即释放占用内存。后续相关源码修改后,编译出ceph-mon执行文件,在测试部16节点环境上跑了两天,所有mon内存均维持在170M以下,问题得到解决。如下为设置no_reply的消息类别:

1、mgr beacon消息

2、pg创建时的消息

3、osd beacon消息

4、osd prepare失败时的消息

个人理解:

社区这样处理该问题感觉是一个暂时的规避措施,每一类消息都应该有beacon机制来追踪状态,现在简单的在预处理的时候设置某类消息状态为no_reply,若该消息mon再接收过程中出现问题,则不会有任何补救措施。最严重的情况就是该消息丢失,但是考虑到mon维护的集群map本身变化不是很频繁,即使丢失掉,下一个时刻会及时重新上报,且mon自身有scrub机制,当peon版本和leader不一致时也会触发同步。所以社区处理办法可以解决该问题。但是个人觉得最好还是补充这类消息的bacon机制(社区开发人员也提到该解决方案,但是工作量会很大),除非某些消息确实不需要bacon来追踪消息状态。

社区帖子:

https://github.com/ceph/ceph/pull/20467

https://github.com/ceph/ceph/pull/20517/files

https://github.com/ceph/ceph/pull/21057/files

社区地址:http://tracker.ceph.com/issues/23077

完整修改地址:https://github.com/ceph/ceph/pull/21016/files

学无止境966 发布了348 篇原创文章 · 获赞 6 · 访问量 9244 私信 关注

标签:问题,monitor,澄清,内存,ceph,消息,com,mon
来源: https://blog.csdn.net/qq_23929673/article/details/100583034