ES版本7.5.2，lucene版本8.3.0
按照段合并参数index.merge.policy.deletes_pct_allowed的默认值33来算的话，docs.deleted数量应该不超过docs.count的一半才对。
我这里有一些update操作比较频繁的索引，查看索引stats信息，发现docs.deleted数量明显大于docs.count，有些deleted数量是count的十几倍。
导致在qps相同的情况下，这种索引查询占用的cpu持续上升，一直到docs.deleted文档被清理的那次合并以后，cpu才会有一个大的降幅。
我想知道为什么这些索引在段合并的时候，deletes_pct_allowed参数的值没有起到作用呢，通过怎样调整段合并参数可以使deleted文档数量能及时被清理呢？
我试了调整以下参数，但从监控上看都没有效果
index.merge.policy.deletes_pct_allowed
index.merge.policy.reclaim_deletes_weight
index.merge.policy.expunge_deletes_allowed
按照段合并参数index.merge.policy.deletes_pct_allowed的默认值33来算的话，docs.deleted数量应该不超过docs.count的一半才对。
我这里有一些update操作比较频繁的索引，查看索引stats信息，发现docs.deleted数量明显大于docs.count，有些deleted数量是count的十几倍。
导致在qps相同的情况下，这种索引查询占用的cpu持续上升，一直到docs.deleted文档被清理的那次合并以后，cpu才会有一个大的降幅。
我想知道为什么这些索引在段合并的时候，deletes_pct_allowed参数的值没有起到作用呢，通过怎样调整段合并参数可以使deleted文档数量能及时被清理呢？
我试了调整以下参数，但从监控上看都没有效果
index.merge.policy.deletes_pct_allowed
index.merge.policy.reclaim_deletes_weight
index.merge.policy.expunge_deletes_allowed
2 个回复
Charele - Cisco4321
赞同来自:
你不能依赖于一个index.merge.policy.deletes_pct_allowed参数，
这只是参数之一，不能说一潢足它肯定就会自动merge。还有其它参数条件。
Charele - Cisco4321
赞同来自:
我没找到在哪