如何检查每个进程的磁盘I / O利用率

我在Linux系统停顿时遇到问题，我发现sysstat / sar报告磁盘I / O利用率，平均服务时间以及系统停顿时的平均等待时间的峰值。

我如何确定下一次发生这些峰值的是哪个过程？
可能与sar有关（即：我可以从已记录的sar文件中找到此信息吗？

输出“ sar -d”，系统停顿发生在12.58-13.01pm左右。

12:40:01          DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
12:40:01       dev8-0     11.57      0.11    710.08     61.36      0.01      0.97      0.37      0.43
12:45:01       dev8-0     13.36      0.00    972.93     72.82      0.01      1.00      0.32      0.43
12:50:01       dev8-0     13.55      0.03    616.56     45.49      0.01      0.70      0.35      0.47
12:55:01       dev8-0     13.99      0.08    917.00     65.55      0.01      0.86      0.37      0.52
13:01:02       dev8-0      6.28      0.00    400.53     63.81      0.89    141.87    141.12     88.59
13:05:01       dev8-0     22.75      0.03    932.13     40.97      0.01      0.65      0.27      0.62
13:10:01       dev8-0     13.11      0.00    634.55     48.42      0.01      0.71      0.38      0.50

这是我昨天开始的一个线程的后续问题：负载和磁盘块等待突然高峰，我希望可以就此问题创建一个新的主题/问题，因为我还无法解决问题。

如果您有幸赶上下一个高峰利用期，则可以使用iotop交互式地研究每个进程的I / O统计信息。

您可以使用pidstat通过以下命令每20秒打印每个进程的累积io统计信息：

# pidstat -dl 20

每行将具有以下列：

• PID-进程ID
• kB_rd / s-导致每秒从磁盘读取任务的千字节数。
• kB_wr / s-任务已导致或应导致每秒将其写入磁盘的千字节数。
• kB_ccwr / s-任务已取消对磁盘的写入的千字节数。当任务截断一些脏页缓存时，可能会发生这种情况。在这种情况下，已经解决了另一个任务的某些IO将不会发生。
• Command-任务的命令名称。

输出看起来像这样：

05:57:12 PM       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
05:57:32 PM       202      0.00      2.40      0.00  jbd2/sda1-8
05:57:32 PM      3000      0.00      0.20      0.00  kdeinit4: plasma-desktop [kdeinit]              

05:57:32 PM       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
05:57:52 PM       202      0.00      0.80      0.00  jbd2/sda1-8
05:57:52 PM       411      0.00      1.20      0.00  jbd2/sda3-8
05:57:52 PM      2791      0.00     37.80      1.00  kdeinit4: kdeinit4 Running...                   
05:57:52 PM      5156      0.00      0.80      0.00  /usr/lib64/chromium/chromium --password-store=kwallet --enable-threaded-compositing 
05:57:52 PM      8651     98.20      0.00      0.00  bash 

05:57:52 PM       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
05:58:12 PM       202      0.00      0.20      0.00  jbd2/sda1-8
05:58:12 PM      3000      0.00      0.80      0.00  kdeinit4: plasma-desktop [kdeinit]              

没有什么比持续监视更胜一筹了，您根本无法在事件发生后恢复对时间敏感的数据...

但是，您可以检查几件事来暗示或消除这些东西- /proc是您的朋友。

sort -n -k 10 /proc/diskstats
sort -n -k 11 /proc/diskstats

字段10、11是累积的写入扇区和累积的时间（ms）写入。这将显示您的热文件系统分区。

cut -d" " -f 1,2,42 /proc/*/stat | sort -n -k +3

这些字段是PID，命令和IO等待等待滴答声。这将显示您的热门进程，尽管只有它们仍在运行。（您可能想忽略文件系统日记线程。）

以上内容的有用性取决于正常运行时间，长时间运行的流程的性质以及文件系统的使用方式。

注意事项：不适用于2.6之前的内核，如果不确定，请检查您的文档。

（现在开始为自己的未来做点事，安装Munin / Nagios / Cacti /随便什么；-)

使用atop。（http://www.atoptool.nl/）

将数据写入压缩文件中，atop以便以后以交互方式读取。每10秒钟读取一次读数（增量）。将其执行1080次（3个小时；因此，如果您忘记了它，输出文件将不会耗尽磁盘空间）：

$ atop -a -w historical_everything.atop 10 1080 &

坏事再次发生后：

（即使它仍在后台运行，它也会每10秒追加一次）

% atop -r historical_everything.atop

既然您说了IO，我会打3个键：tdD

t - move forward to the next data gathering (10 seconds)
d - show the disk io oriented information per process
D - sort the processes based on disk activity
T - go backwards 1 data point (10 seconds probably)
h - bring up help
b - jump to a time (nearest prior datapoint) - e.g. b12:00 - only jumps forward
1 - display per second instead of delta since last datapiont in the upper half of the display

使用btrace。例如，它很容易使用btrace /dev/sda。如果该命令不可用，则可能在软件包blktrace中可用。

编辑：由于在内核中未启用debugfs，您可以尝试执行date >>/tmp/wtf && ps -eo "cmd,pid,min_flt,maj_flt" >>/tmp/wtf类似操作。记录页面错误当然与使用btrace完全不同，但是如果幸运的话，它可能会给您一些有关磁盘占用最大进程的提示。我只是尝试在我最密集的I / O服务器中安装一台，并列出其中包括我知道正在消耗大量I / O的进程。