2.5.3 升级到2.5.6 升级一个be，从日志中发现大量compaction任务加入，很快打满了compaction pool，后面任务加入不进去。 然后cpu被打满。立马回退回2.5.3 不再有问题。
19:37 分的时候升级的， be日志如下
链接: https://pan.baidu.com/s/1XeuU0Xw4sFZ9lxoC7SIy8Q 提取码: 96xs
您好，能提供回滚到2.5.3后的日志吗，另外辛苦看一下之前的监控，在升级前几天有出现过compaction打满cpu的情况吗。
- 因为我们这个集群是内部BI用的，纯说cpu打满，大概率是大查询导致的。 但没发现比较正常的时间点出现打满的情况。
- 我看了几个节点的compaction task queue的大小，最大在200左右，没有出现这次1000妥妥不够的情况。
3.这个图有用吗，看监控只找到了这个，
你好，我研究下size_tiered_compaction_policy里的策略，结合日志
我感觉是因为大量table 被force_base_compaction 条件下，segment数量大于等于2 就会触发compaction
而在2.5.3 默认要大于5的样子，从而 导致compaction 频率增加。但增加的有点过大的了把，量化不来。
老版本的策略中也是大于5才会触发compaction，这里是为了保持兼容，避免用户升级后compaction太频繁了。force_base_compaction是定期触发的，目前唯一的触发条件是距离上次base compaction的时间，所以2.5.8版本里会考虑当前compaction的负载，避免短时间内compactioin负载飙升。同时也因为通常的compaction需要至少segment大于5才触发，所以定期的base compaction需要把这部分tablet的都做掉，不然后续如果没有新的导入可能永远不会做了。
嗯，所以我们升级发生的问题是因为2.5.3 -》 2.5.6的代码变更中，在force_base_compaction 下，会把min_compaction_segment_num = 2, 这就使得对老的，没有新的数据导入的分区，造成了巨大的compaction压力。