我最近将ES从1.5.2升级到2.2.0版本并添加了Shield。我试图通过使用Locust来执行压力测试，该How can I have JAXB call a method after it has completed unmarshalling an XML file into an object?使用数据（通过nodejs app）爆炸集群。 与之前的压力测试（1.5.2）相比，我得到了奇怪的结果：
1.5.2 ver 2.2.0 ver
cpu 50% avg, 90% peak 87% avg, 96% peak
IOPS 30 avg, 300 peak 800 avg, 1122 peak
为什么ES如此努力？
我无法理解的另一个奇怪的事情，我认为与上面有关，是插件头中的输出。 以前（1.5.2）我看到索引存储数据为：
INDEX_NAME
尺寸：10.3Gi（20.6Gi）
docs：17,073,010（17,073,010）
但现在（2.2.0）它是：
INDEX_NAME
尺寸：13.7Gi（29.3Gi）
docs：10,217,220（20,434,440）
正如您所看到的，数据在ES 2.2.0中加倍，为什么会发生这种情况？ 我的v2.2.0 ES配置有问题吗？
答案 0 :(得分：4)
我在Elasticsearch community forum得到了答案。
Zachary Tong的回答：
同意@rusty提出的观点：默认情况下，Doc值会增加一些CPU / IO开销和一些磁盘空间，现在每个操作（而不是每5秒）的translog刷新以及副本问题。
除此之外，Lucene层也发生了变化。传入的文本blob，但是tl; dr是Lucene识别空闲资源并利用它们，使资源使用看起来更高，因为它真的只是让工作更快完成。
因此，在Elasticsearch 1.x中，我们强行扼杀了Lucene的段合并过程，以防止它过度饱和您的节点/集群。
问题是严格的门槛几乎不是正确的答案。如果要进行大量索引，通常需要增加阈值以使Lucene使用所有CPU和磁盘IO。如果您没有很多索引，则可能希望阈值更低。但是，当群集相对空闲时，您还希望它能够“突破”一次性合并的限制。
在Lucene 5.x（用于ES 2.0+）中，他们添加了一种新的合并限制方式，用于监控索引的活跃程度，并自动调整限制阈值（请参阅https://issues.apache.org/jira/browse/LUCENE-61191，{{3} }和https://github.com/elastic/elasticsearch/pull/92431）。
实际上，这意味着您的索引在ES 2.0+中往往更快，因为允许段以您的群集可以处理的速度进行合并，而不会使群集过度饱和。但这也意味着您的群集将很乐意使用任何空闲资源，这就是您看到更多资源利用率的原因。
基本上，Lucene发现这些资源没有被使用......所以它让他们更快地完成任务。