ES查询慢

背景：使用ES查询链路日志数据，查询很慢。

排查：

1. 查看分片大小

一个索引有12片，每片的大小只有几个、10几个G。

分片过多ES进行查询的时候会扫每个分片的数据，导致性能下降。不单是查询，对写入也会有影响。

分片的大小保持在10GB-50GB之间
分片大小保持在10GB-50GB之间，大的分片在故障恢复时会占用较长的时间。当某个节点发生故障时，Elasticsearch会根据剩余节点的数据自动的重新平衡分片。恢复进程通常是在网络之间拷贝分片的内容，因此一个100GB的分片会比50GB的分片花费更多的时间。相比之下，小分片的开销更大，搜索效率也更低。搜索50个1GB分片将比搜索一个包含相同数据的50GB分片占用更多资源。分片的大小并没有强制的限制。但经验值是10-50GB之间的分片通常在日志和时间序列的数据流索引上表现更好。 总结：打分片性能好，故障恢复慢，小分片性能差，故障恢复快。

方案：

将索引的分片改为6片。

2. 看内存

给ES的JVM内存32G，所以怀疑留给lucene的内存太小了，所以导致的慢。

因为ES 堆内存的分配需要满足以下两个原则：

不要超过物理内存的 50%。 Lucene 的设计目的是把底层 OS 里的数据缓存到内存中。

Lucene的段是分别存储到单个文件中的，这些文件都是不会变化的，所以很利于缓存，同时操作系统也会把这些段文件缓存起来，以便更快的访问。如果我们设置的堆内存过大，Lucene 可用的内存将会减少，就会严重影响降低 Lucene 的全文本查询性能。

方案：

让Xmx 和 Xms 的大小是相同的。其目的是为了能够在 Java 垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小而浪费资源，可以减轻伸缩堆大小带来的压力。

调小JVM，给Lucene留有足够的空间。后续也最好不要超过32G（物理机内存的一半）。

结果：

查询正常。