我们在 12 核、96GB RAM、4 台旋转磁盘机上运行 4 节点/机器弹性搜索集群。在正常运行下，大多数 CPU 使用率是用户，约为 5-10%。每隔几天，其中一台机器的 CPU 使用率就会达到 80-100%，并且全部是用户和系统——io 等待实际上减少了。我们最初认为这是一个特定于 elasticsearch 的问题，但经过大量调试后似乎并非如此：
- elasticsearch 节点进程重启后 CPU 利用率仍然很高
- elasticsearch 线程全部正常运行，只是耗时增加了 10 倍。
- 非 elasticsearch 操作（gc collection）也需要 10 倍的时间，但堆活动正常
如果我们停止该过程约一小时，然后仅重新启动该过程（而不是机器），问题就会消失并且一切可以正常工作几天。
我们还注意到，在出现问题期间，磁盘复制测试非常缓慢。当进程启动但处于空闲状态（未索引/搜索数据）或进程停止后不久，通过 dd 复制 1GB 文件在有问题的机器上的速度约为 18MB/s，但在正常情况下速度为 490MB/s。有趣的是，我们使用 dstat 注意到，缓慢的复制大约需要 25 秒才能执行任何 i/o，然后又需要 30 秒才能完成。strace 输出似乎没有明显不同。
知道我们还可以进行哪些进一步的测试吗？
答案1
Elastic Search 存在很多问题，通过快速谷歌搜索，您可以找到一些。但高 CPU 使用率的主要问题可能是由于缺乏对缓存使用的控制。请参考以下内容：
https://github.com/elasticsearch/elasticsearch/issues/4288 http://elasticsearch-users.115913.n3.nabble.com/Very-high-sys-cpu-usage-with-HTTP-KeepAlive-td4049998.html http://blog.sematext.com/2012/05/17/elasticsearch-cache-usage/
答案2
正如 Ian Macintosh 所建议的那样，使用大量 CPU 的进程应该显示在顶部，但由于它基于定期对进程表进行采样，因此可见性可能取决于这些进程的运行时间。
GNU 会计实用程序对于此类事情也非常有用。（在基于 Debian 的系统上，软件包 = 'acct'；在基于 Redhat 的系统上，软件包 = 'psacct'）。我经常在 atop 上运行，并在accton on大多数服务器上安装会计软件包 ( )。
启用会计数据收集后，将保存每个运行进程的 CPU 使用率统计信息，以及进程开始和结束运行的时间。当一堆短暂的进程消耗 CPU 时，这可能非常有用，而使用 atop、strace 等很难发现这种情况（尽管 strace 在使用-f或-ff标志时可能更有帮助）。当进程的生命周期比 CPU 峰值长得多时，它就没那么有用了，但在这些情况下，atop 应该能满足您的需求。 lastcomm可能是您访问收集到的统计数据所需的工具。
虽然 strace 非常有用，但它只能告诉你有关系统调用的信息。如果你有什么东西大量使用 CPU，但没有调用系统，它就不会显示出来。有时 ltrace 对此很有用，但同样，只有当相关活动发生在库调用中时，情况并非总是如此。
只有在确定了消耗 CPU 的进程后，strace 和 ltrace 等工具，甚至 gdb 等调试器才会发挥作用，但听起来你还没有找到。此时，atop 和 lastcomm 可能是最佳选择。
答案3
您可以进行哪些进一步的测试？
（缺少一些信息，例如与用户 CPU 百分比相比系统 CPU 百分比是多少，但请检查 CPU 的 IRQ 百分比是多少，以防万一出现问题。
假设系统 CPU % 相当高，而且不是 IRQ，您可能需要检查内存。atop 是一个方便的概览工具，它应该会告诉您是否因为内存压力过大而导致页面扫描或页面窃取之类的问题。
我假设您已经排除了交换作为一个问题的可能性。
因为 atop 可以让你全面了解机器状态，所以它对于掌握整体状态非常方便。它有助于比较正常运行的系统和运行不正常的系统上的 atop。
如果仅有的异常是用户 CPU % 并且系统本身运行正常，否则，您很可能正在处理软件错误，并且必须向作者寻求帮助 - 或者改变您使用它的方式以避免触发您发现的任何错误。只需检查您是否在处理自己的错误 - 即，您调用错误或处于循环或类似性质。我已经见过几次了。
总之，深入研究内存、中断、交换等，看看是否可以排除这些 - 我建议在顶部快速比较正常行为和异常行为并突出显示关键项目。