最近遇到Monitor容量一直增长，直到达到设定的上线，自动退出，有时候Monitor还需要重
建。 我们先是从Monitor代码层面去研究，是否有未合并的BUG（我们使用的是0.94.5版
本），没有发现有跟压缩相关的问题单，在ceph社区群里询问，有成都的同行在jewel
10.2.10也遇到过类似问题，后来总结出是Leveldb的问题，对于Leveldb不熟，走读代码，
修改BUG，测试，大半年或许一年时间就过去了~~~
Redhat官方针对该问题，给出的解决方案是执行
ceph tell mon.xxx compact
后面，改用定时任务，定时去执行上面的命令，有点土，但很有效~~~
后台任务在执行上述命令时，如果压缩数据量比较大，比如我们遇到过的压缩75GB的数据，压缩时间长达
70s，看过Monitor代码的都知道， 这条压缩命令是同步的，会阻塞后续所有的msg，导致monitor的
Paxos机制失效，其余Monitor会重新选举出新的Leader，压缩Leveldb的Monitor直接down掉，直到
compact任务结束，重新发起选举，该Monitor重新上线。
最后，修改compact命令为异步模式，下发压缩命令后，直接将任务添加后现有的压缩线程中，由压缩线
程去执行compact all,之前还怀疑过，会不会阻塞写，经过大量测试，压缩不会阻塞写，Monitor还是
正常工作！我觉得我下面修改的PATCH并不是完美的，我认为可以在后台统计Monitor容量线程中加入判
断，如果容量超过一个阈值，将全局压缩的任务添加到压缩队列中，这样才完美。
附上我的PATCH链接：
https://github.com/penglaiyxy/ceph/commit/86bcfd2ccb349ccc05512d8df9deaf9b368524db
补充(2019-07-23)：
这个问题可能在0.94.6版本就解决了： https://github.com/ceph/ceph/commit/91093041a86fda40de08a366b5118e5e3ae275f0#diff-689566e884e416fce50c10ff4438f936
根据部署ceph10.2.10版本的经验，没有出现过Monitor容量持续增长的情况，上面的解决方案应该靠谱。
欢迎大家讨论！
