我有一个拖延的Linux系统的问题,我发现sysstat / sar报告磁盘I / O利用率,平均服务时间以及在系统停顿时的平均等待时间的巨大峰值。
我怎么能确定哪一个过程在下一次发生的时候导致这些高峰?
是否有可能做与萨尔(即:我可以find这个信息从alreade录制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
这是我昨天开始的一个线程的后续问题: 负载和磁盘块等待突然出现的高峰 ,我希望可以确定的是,我创build了一个新的话题/问题,因为我还没有能够解决问题。
如果您足够幸运能够赶上下一个高峰使用期,您可以使用iotop交互式学习每个进程的I / O统计信息。
您可以使用pidstat使用此命令每20秒打印每个进程的累积io统计信息:
# pidstat -dl 20
每一行都有以下的列:
输出如下所示:
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 /仙人掌/任何;-)
使用atop。 ( http://www.atoptool.nl/ )
将数据写入一个压缩文件,该压缩文件可以稍后以交互式的方式读取。 每10秒钟读取一次(delta)。 做1080倍(3小时;所以如果你忘了它的输出文件将不会运行你的磁盘)atop -a -w historical_everything.atop 10 1080&
坏事再次发生后:
(即使它仍然在后台运行,它只是每10秒追加一次)
at -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) - eg 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
或类似的。 logging页面错误当然与使用btrace完全不一样,但如果幸运的话,它可能会给你一些关于大多数磁盘饥饿进程的提示。 我只是尝试了大多数I / O密集型服务器上的那一个,列表包括我知道消耗大量I / O的进程。