前言
在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