Linux CPU使用率和进程执行历史记录

有什么方法可以查看导致CPU使用率最高的进程？

我有AMAZON EC2 Linux，其CPU利用率达到100％，并让我重新启动系统。我什至无法通过SSH（使用腻子）登录。

有什么方法可以查看导致如此高的CPU使用率的原因以及导致该情况的进程吗？

我了解sar和top执行命令，但是在任何地方都找不到进程执行历史。这是来自Amazon EC2监视工具的图像，但我想知道是哪个进程引起的：

我也曾尝试过，ps -eo pcpu,args | sort -k 1 -r | head -100但没有运气找到如此高的CPU使用率。

您可以通过以下两种方法进行操作。请注意，完全有可能在一个失控的场景中导致许多进程，而不仅仅是一个。

第一种方法是将pidstat设置为在后台运行并生成数据。

pidstat -u 600 >/var/log/pidstats.log & disown $!

这将使您以十分钟的间隔非常详细地了解系统的运行情况。我建议这是您的首选，因为它可以生成最有价值/最可靠的数据。

这有一个问题，主要是如果盒子进入失控的cpu循环并产生巨大的负载-您不能保证实际的过程会在负载期间及时执行（如果有的话），因此您实际上可能会错过输出！

查找此内容的第二种方法是启用流程记帐。可能更多是长期选择。

accton on

这将启用流程记帐（如果尚未添加）。如果未运行，则需要一定时间才能运行。

已经运行了24小时-您可以运行这样的命令（将产生如下输出）

# sa --percentages --separate-times
     108  100.00%       7.84re  100.00%       0.00u  100.00%       0.00s  100.00%         0avio     19803k
       2    1.85%       0.00re    0.05%       0.00u   75.00%       0.00s    0.00%         0avio     29328k   troff
       2    1.85%       0.37re    4.73%       0.00u   25.00%       0.00s   44.44%         0avio     29632k   man
       7    6.48%       0.00re    0.01%       0.00u    0.00%       0.00s   44.44%         0avio     28400k   ps
       4    3.70%       0.00re    0.02%       0.00u    0.00%       0.00s   11.11%         0avio      9753k   ***other*
      26   24.07%       0.08re    1.01%       0.00u    0.00%       0.00s    0.00%         0avio      1130k   sa
      14   12.96%       0.00re    0.01%       0.00u    0.00%       0.00s    0.00%         0avio     28544k   ksmtuned*
      14   12.96%       0.00re    0.01%       0.00u    0.00%       0.00s    0.00%         0avio     28096k   awk
      14   12.96%       0.00re    0.01%       0.00u    0.00%       0.00s    0.00%         0avio     29623k   man*
       7    6.48%       7.00re   89.26%       0.00u    0.00%       0.00s    

列的排序方式如下：

1. 通话次数
2. 通话百分比
3. 在这种类型的所有流程上花费的实时时间。
4. 百分比。
5. 用户CPU时间
6. 百分比
7. 系统CPU时间。
8. 平均IO调用。
9. 百分比
10. 指令名称

您要查找的是生成最多用户/系统CPU时间的进程类型。

这会将数据分解为CPU时间总量（第一行），然后细分该CPU时间的分配方式。进程计费仅在进程启动时才正确计费，因此，最好在启用它以确保考虑所有服务后重新启动系统。

实际上，这决不会给您一个确定的想法，它可能是导致此问题的过程，但可能会给您带来良好的感觉。由于可能是24小时快照，因此结果可能会出现偏差，因此请记住这一点。它也应该始终记录日志，因为它具有内核功能，并且与pidstat不同，即使在重负载期间也始终会产生输出。

可用的最后一个选项还使用进程记帐，因此您可以如上所述将其打开，但是使用程序“ lastcomm”可以生成问题发生时执行的进程的一些统计信息以及每个进程的cpu统计信息。

lastcomm | grep "May  8 22:[01234]"
kworker/1:0       F    root     __         0.00 secs Tue May  8 22:20
sleep                  root     __         0.00 secs Tue May  8 22:49
sa                     root     pts/0      0.00 secs Tue May  8 22:49
sa                     root     pts/0      0.00 secs Tue May  8 22:49
sa                   X root     pts/0      0.00 secs Tue May  8 22:49
ksmtuned          F    root     __         0.00 secs Tue May  8 22:49
awk                    root     __         0.00 secs Tue May  8 22:49

这也可能会给您一些提示，指出可能是什么引起了问题。

Atop是一个特别方便的守护程序，用于查看对流程级别的深入分析，并且默认情况下将这些数据存档28天。除了提供令人敬畏的实时监控界面外，您还可以指定要打开并逐步浏览的那些日志文件。

该文章给出的能力的一些想法，你可以找到更多的手册页。

这确实是一个很棒的软件。

程序如psmon和monit的你也许有帮助。它们可以监视系统上正在运行的进程，如果超过了任何阈值（CPU使用率，内存使用率...），则可以设置它们向您发送有关正在发生的事情的电子邮件报告。

也可以自动重启行为异常的进程。

一种解决方案是编写一个脚本，该脚本通过一分钟的cron或在睡眠循环中运行，并向您发送电子邮件/ scp作业/转储到ebs卷...并提供相关输出（dmesg，pstree -pa和ps aux，可能是vmstat）会发现超过一定限制的平均负载...