我对 Elasticsearch 相当陌生，并且遇到了一个问题，甚至在故障排除方面都遇到了困难。即使没有进行搜索或索引，我的 Elasticsearch (1.1.1) 目前的 CPU 利用率仍然很高。 CPU 使用率并不总是 100%，但它会大幅上升并且负载非常高。
之前，该节点上的索引连续几个月运行得很好，没有出现任何问题。这是今天才开始的，我不知道是什么原因造成的。
即使我重新启动ES，问题仍然存在，甚至在绝望中重新启动服务器。对这个问题没有影响。
这里有一些统计数据可以帮助解决问题，但我想还需要更多信息。我只是不确定要提供什么。
Elasticsearch 1.1.1
Gentoo Linux 3.12.13
java版本“1.6.0_27”
OpenJDK 运行时环境 (IcedTea6 1.12.7) (Gentoo build 1.6.0_27-b27)
OpenJDK 64 位服务器虚拟机(版本 20.0-b12，混合模式)
一个节点，5个分片，0个副本
系统上有 32GB RAM，16GB 专用于 Elasticsearch
RAM 似乎不是这里的问题。
任何有关解决问题的提示将不胜感激。
编辑:来自顶部的信息(如果有帮助的话)。
top - 19:56:56 up 3:22, 2 users, load average: 10.62, 11.15, 9.37
Tasks: 123 total, 1 running, 122 sleeping, 0 stopped, 0 zombie
%Cpu(s): 98.5 us, 0.6 sy, 0.0 ni, 0.7 id, 0.2 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 32881532 total, 31714120 used, 1167412 free, 187744 buffers
KiB Swap: 4194300 total, 0 used, 4194300 free, 12615280 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2531 elastic+ 20 0 0.385t 0.020t 3.388g S 791.9 64.9 706:00.21 java
最佳答案
正如 Andy Pryor 提到的，后台合并可能是导致问题的原因。我们的索引展期已暂停，当前的两个索引超过 200GB。将它们翻过来似乎解决了问题，从那以后我们一直相处得很好。
编辑: 看似闲置时的高负载被确定是由几个非常大的指数合并造成的，这些指数没有每周展期。这是每周更新指数的内部流程的失败。解决了这一疏忽后，合并时间缩短了，高负载也减轻了。
关于Elasticsearch 空闲时 CPU 高，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/23394220/