我们在12个核心，96GB RAM，4个旋转磁盘机器上运行4节点/机器弹性search群集。 在正常的操作下，大部分的CPU使用率是用户的，大约在5-10％。 每隔几天，机器的一个CPU使用率就会达到80-100％，所有的用户和系统 – 实际上等待下降。 我们首先认为这是一个弹性search的具体问题，但广泛的debugging后，似乎并不是这样：
如果我们停止大约一个小时的过程，然后只重新启动过程（而不是机器），问题就会消失，事情会很好的工作几天。
我们也注意到在这个问题上，磁盘拷贝testing非常慢。 在进程已经启动但空闲的情况下（不是索引/search数据），或者在进程停止后不久，通过dd复制1GB文件在有问题的机器上以约18MB / s的速度发生，而在健康状态下则以490MB / s的速度发生。 有趣的是，我们注意到使用dstat，在执行任何I / O操作之前，慢速复制需要大约25秒，然后再花30秒完成。 strace产量似乎没有明显的不同。
任何想法，我们可以运行进一步的testing？
使用弹性search有很多问题，并通过快速search，你可以find一些。 但高CPU使用率的主要问题可能是由于对高速caching使用的控制不足造成的。 请在下面参考：
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/
使用大量CPU的进程应该按照Ian Macintosh的build议显示，但是因为它是基于定期循环对进程表进行采样，所以可见性可能取决于进程运行的时间。
GNU会计工具也可以对这类事情非常有用。 （基于debian的系统上的package ='acct'，或者基于redhat的系统上的'psacct'）。 我经常在上面运行，而且大多数服务器accton on都有会计软件包（ accton on ）。
在启用记帐数据收集后，统计信息将保持有关运行的每个进程的CPU使用情况，以及wqith在启动和结束运行时的情况。 当一堆短命的进程消耗你的cpu时，这是非常有用的，这很难用atop，strace等来查看（尽pipestrace可能对-f或-ff标志更有帮助）。 当你的生命周期比CPU的寿命要长得多时，它就没那么有用了，但是在那些情况下，应该给你想要的东西。 lastcomm可能是您想要访问收集的统计信息的工具。
虽然非常有用，strace只会告诉你系统调用。 如果你有一些使用cpu的东西，而不是调用系统，它不会显示出来。 有时ltrace可以用于此，但是只有当相关活动发生在库调用中时，情况并非总是如此。
像strace和ltrace这样的工具，甚至像gdb这样的debugging器，只有在确定了正在消耗CPU的进程之后才会起作用，而且听起来并不像现在这样。 在这一点上，可能是最后一个通行证。
你可以运行什么进一步的testing？
（缺less一些信息，比如当挂钩用户CPU％时系统CPU％是什么），但是检查CPU是IRQ的百分比，以防万一。
假设系统CPU％相当高，而且不是IRQ的，你可能要检查内存。 一个方便的概述工具是顶部，它应该告诉你，如页面扫描或页面窃取是否正在造成，因为你是在沉重的内存压力。
我会假设你已经排除了交换作为一个问题。
因为atop给你一个相当全面的机器状态概览，所以在处理整个状态时非常方便。 这将有助于比较正确的操作系统和不正确的操作系统。
如果唯一的exception是用户CPU％，而且系统本身运行正常，那么你可能会遇到一个软件错误，将不得不恢复到作者的帮助 – 或改变你使用它的方式，以避免触发你find的错误。 只要检查一下你是不是在处理自己的错误 – 也就是说，你是在严重地调用它，或者是在一个循环中，或者是某种性质的东西。 我已经看过几次了。
总之，挖掘内存，irq，交换等，看看你是否可以排除这些 – 我build议在正常行为和exception行为之间进行快速比较，并突出重点项目。