标签：问题 monitor 澄清 内存 ceph 消息 com mon
前言
在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
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。