我如何才能看到几秒钟前哪个进程使 CPU 使用率飙升并冻结了系统?

Dan*_*scu 14 cpu-load

我的 Ubuntu 18.04 随机冻结了几秒钟。我可以移动鼠标光标(有时),但否则操作系统没有响应,我无法切换到任何其他应用程序。

当它恢复时,我可以转到系统监视器并看到几秒钟前 CPU 使用率的峰值(尽管只有 70%),但这并不能告诉我当时 CPU 的使用情况。

您如何找出最近处理 CPU 的进程?(我不认为这是由于磁盘 I/O 造成的)。

更新:与此同时,我通过隔离可疑应用程序确定罪魁祸首是 WebStorm,这一个基于 Java 的 IDE。使用 VS Code 时,没有冻结。

以下是评论中要求的一些其他诊断信息。

$ free -h
              total        used        free      shared  buff/cache   available
Mem:            15G        8.6G        2.3G        2.0G        4.5G        4.4G
Swap:           15G        487M         15G
$ sysctl vm.swappiness
vm.swappiness = 10
Run Code Online (Sandbox Code Playgroud)

当 WebStorm 冻结时,系统监视器中的负载确实会出现峰值,但远未达到 100%。

Col*_*ing 10

除非使用一种捕获 CPU 活动的工具监视系统,否则不可能获得 CPU 利用率的历史记录。一种方法是运行 cpustat 并捕获输出并查看 CPU 利用率发生的位置,例如:

sudo apt-get install cpustat
cpustat -xS | tee cpu.log
Run Code Online (Sandbox Code Playgroud)

当您减速时,您可以查看 cpu.log 并查看正在忙于运行的内容。


ari*_*ica 10

尝试atop

通过系统状态快照连续捕获过去活动的一种更图形化的方法是使用atop. atop类似于top或 等程序htop,显着区别在于它运行定期 cron 作业来生成和保存完整的进程和系统活动数据。这使您可以稍后返回过去调查问题。还提供了类似于传统 Unix 的atop实用程序。两个实用程序共享相同的系统数据快照数据库。atopsarsar

这是atop显示磁盘利用率压力下的系统的屏幕截图。请注意 LVM 上的 100% 磁盘利用率sda,以红色突出显示。图片来源:atop作者 Gerlof Langeveld,atoptool.nl

屏幕顶部以红色显示磁盘利用率压力(来源 Gerlof Langeveld,atoptool.nl)

安装:

    sudo apt-get install atop
Run Code Online (Sandbox Code Playgroud)

现在,您需要等待约 10 分钟才能执行第一个记帐快照。快照使用每个实体的每个指标点。跟踪的实体有:

  • 进程(按可执行文件)
  • 每核 CPU 利用率、频率和扩展、系统与用户
  • 内存和交换空间使用情况
  • 磁盘分区:读取、写入、利用率百分比
  • 网络接口:数据包输入/输出(UDP 和 TCP)、错误、数据包重传等

所有指标都是所观察快照的累积总计。

查看过去的活动

这有效地为您提供了一个小“时间机器”。您可以及时前后移动,查看过去观看的日子中每个时间片中发生的情况。

   atop -r [/var/log/atop/...]
Run Code Online (Sandbox Code Playgroud)

如果没有快照文件参数,atop将显示过去一天的视图(选择任何现有的快照文件以显示不同的一天),从午夜开始。要记住的最重要的关键是:

t         时间向前移动(到下一个时间片)

T         时间向后移动(到前一个时间片)

h         帮助

q         辞职

快照增量是通过在每个进程中使用进程记帐来正确实现的exit(),因此即使您有许多短期运行的进程,它们的各部分总和也会被添加在一起并正确归因于适当的可执行文件和适当的时间片。

不仅捕获进程。捕获完整的系统状态。屏幕的上半部分显示每个实体的所有重要系统指标、CPU、内存、磁盘和网络利用率。这些数据包括 CPU 频率和比例因子、网络错误等等。为了提供更多帮助,异常值会以颜色突出显示,例如,任何 100% 的时间片磁盘利用率都将显示为亮红色,接近最大的值将以不同的颜色显示,因此任何压力过大的实体都很难错过。

如果您更喜欢批处理风格,您可能更喜欢使用atopsarover atop。例如,要转储完整时间范围的批处理样式,您可以使用:

   atopsar -D -b 14:05 -e 14:45
Run Code Online (Sandbox Code Playgroud)

其中将显示今天 ( : begin) 14:05 和 ( : end) 14:45-D之间磁盘利用率 ( )%排名前 3 的进程。更详细的使用方法。-b-eman atopsar

如果您想专注于某些子区域,您可以使用这些atopsar选项(atop交互使用相同的字母):

    -C  sort processes in order of cpu-consumption (default)
    -M  sort processes in order of memory-consumption
    -D  sort processes in order of disk-activity
    -N  sort processes in order of network-activity
    -A  sort processes in order of most active resource (auto mode)
Run Code Online (Sandbox Code Playgroud)

atop您还可以使用和做更多事情atopsar。使用man atopman atopsar获取完整详细信息。以上就是其要点。


mar*_*elm 6

根据我的经验,Linux 很少因为 CPU 使用而变得无响应。过多的 CPU 使用往往只会让一切变得有点迟钝。

另一方面,I/O 问题(写入许多/大文件、交换、磁盘故障等)很容易导致无响应,一切似乎都停止了,然后可能会继续一段时间,然后再次停止。有时甚至您的鼠标停止移动这一事实使我相信您的问题属于这一类。

确定 I/O 是否是罪魁祸首的一种相当简单且有效的方法是使用标准工具vmstat。您可以在vmstat -w 5某个地方运行(在 中screen,或仅在终端中);这将每 5 秒打印一行统计信息。然后,您可以在遇到冻结后返回并检查数字(和/或将它们张贴在 AskUbuntu 上;)。

输出如下所示:

procs -----------------------memory---------------------- ---swap-- -----io---- -system-- --------cpu--------
 r  b         swpd         free         buff        cache   si   so    bi    bo   in   cs  us  sy  id  wa  st
 3  0       865332       328876     18014392      8262980    0    0   108    89    7    7  21   6  73   0   0
 0  0       865332       330016     18006044      8267348    0    1     0   332 2169 8117  25   6  69   0   0
Run Code Online (Sandbox Code Playgroud)

有趣的列(为此目的)包括:

  • CPU:wa指明了CPU的百分比被阻止WA iting用于I / O到结束。这里的高数字表明 I/O 是问题,而不是 CPU 使用率。也可用于确定瓶颈。
  • 交换:siso显示KIB S的数量交换/进出分别。如果你有足够的内存,应该几乎是 0。高数字表明您的内存需求超过了您的内存大小。
  • I/O:bibo显示从磁盘读取/写入的 KiB/s 数(交换活动包括在此)。意外的高写入数字可能需要搜索正在执行该写入的进程(使用例如iotop)。低/中数字冻结表明您的磁盘很慢。