DISK 100% BUSY,谁造成的?
2016-11-17 16:18
435 查看
iostat等命令看到的是系统级的统计,如果要追查是哪个进程导致的I/O繁忙,应该怎么办?
iostat等命令看到的是系统级的统计,比如下例中我们看到/dev/sdb很忙,如果要追查是哪个进程导致的I/O繁忙,应该怎么办?
# iostat -xd
...
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb 0.00 0.00 6781.67 0.00 3390.83 0.00 1.00 0.85 0.13 0.13 0.00 0.13 85.03
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
...
进程的内核数据结构中包含了I/O数量的统计:
struct task_struct {
...
struct task_io_accounting ioac;
...
};
可以直接在 /proc/<pid>/io 中看到:
# cat /proc/3088/io
rchar: 125119 //在read(),pread(),readv(),sendfile等系统调用中读取的字节数
wchar: 632 //在write(),pwrite(),writev(),sendfile等系统调用中写入的字节数
syscr: 111 //调用read(),pread(),readv(),sendfile等系统调用的次数
syscw: 79 //调用write(),pwrite(),writev(),sendfile等系统调用的次数
read_bytes: 425984 //进程读取的物理I/O字节数,包括mmap pagein,在submit_bio()中统计的
write_bytes: 0 //进程写出的物理I/O字节数,包括mmap pageout,在submit_bio()中统计的
cancelled_write_bytes: 0 //如果进程截短了cache中的文件,事实上就减少了原本要发生的写I/O
我们关心的是实际发生的物理I/O,从上面的注释可知,应该关注 read_bytes 和 write_bytes。请注意这都是历史累计值,从进程开始执行之初就一直累加。如果要观察动态变化情况,可以使用 pidstat 命令,它就是利用了/proc/<pid>/io 中的原始数据计算单位时间内的增量:
# pidstat -d 2 2
Linux 3.10.0-229.14.1.el7.x86_64 (bj71s060) 11/16/2016 _x86_64_ (2 CPU)
12:30:15 PM UID PID kB_rd/s kB_wr/s kB_ccwr/s Command
12:30:17 PM 0 14772 3362.25 0.00 0.00 dd
12:30:17 PM UID PID kB_rd/s kB_wr/s kB_ccwr/s Command
12:30:19 PM 0 14772 3371.25 0.00 0.00 dd
另外还有一个常用的命令 iotop 也可以观察进程的动态I/O:
Actual DISK READ: 3.31 M/s | Actual DISK WRITE: 0.00 B/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
14772 be/4 root 3.31 M/s 0.00 B/s 0.00 % 61.99 % dd if=/de~lag=direct
1 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % systemd -~rialize 24
2 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kthreadd]
...
pidstat 和 iotop 也有不足之处,它们无法具体到某个硬盘设备,如果系统中有很多硬盘设备,都在忙,而我们只想看某一个特定的硬盘的I/O来自哪些进程,这两个命令就帮不上忙了。怎么办呢?可以用上万能工具SystemTap。比如:我们希望找出访问/dev/sdb的进程,可以用下列脚本,它的原理是对submit_bio下探针:
#! /usr/bin/env stap
global device_of_interest
probe begin {
device_of_interest = $1
printf ("device of interest: 0x%x\n", device_of_interest)
}
probe kernel.function("submit_bio")
{
dev = $bio->bi_bdev->bd_dev
if (dev == device_of_interest)
printf ("[%s](%d) dev:0x%x rw:%d size:%d\n",
execname(), pid(), dev, $rw, $bio->bi_size)
}
这个脚本需要在命令行参数中指定需要监控的硬盘设备号,得到这个设备号的方法如下:
# ll /dev/sdb
brw-rw----. 1 root disk 8, 16 Oct 24 15:52 /dev/sdb
Major number(12-bit): 8 i.e. 0x8
Minor number(20-bit): 16 i.e. 0x00010
合在一起得到设备号: 0x800010
执行脚本,我们看到:
# ./dev_task_io.stp 0x800010
device of interest: 0x800010
[dd](31202) dev:0x800010 rw:0 size:512
[dd](31202) dev:0x800010 rw:0 size:512
[dd](31202) dev:0x800010 rw:0 size:512
[dd](31202) dev:0x800010 rw:0 size:512
...
结果很令人满意,我们看到是进程号为31202的dd命令在对/dev/sdb进行读操作。
原文链接
相关文章推荐
- Windows 8 Disk Usage Keep up 100%
- umount.nfs device busy day virsh extend diskSpace, attachDisk
- 虚拟机意外蓝屏造成错误,Cannot open the disk 'E:/xuniji/songxiujie-PC'or one of the snapshot disks it depends on
- PHP Hash冲突,造成CPU 100%,完全解决方案 推荐
- LoadRunner性能测试--%Disk Time 计数器值超过100%
- 性能计数器说明 %disk time超过100% ?
- Troubleshooting the "device is busy" Error Attempting to umount a Disk
- % Disk Time 计数器值超过100%
- Windows 10 - Task Manager Reports 100% Disk Utilization
- % Disk Time 计数器值超过100%
- 前Nginx后Tomcat,使用SmartUpload上传组件可能造成CPU100%内存占用率冲高
- 强制卸载busy的disk
- IIS出错造成inetinfo.exe进程占用CPU100%
- 造成CPU使用100%的几个原因(转载)
- Ubuntu磁盘使用率100%造成MySQL服务无法继续运行
- php 随机记录mysql rand()造成CPU 100%的解决办法
- NET VBCSCompiler.exe占用100%,造成项目卡顿的的解决方法
- IIS出错造成inetinfo.exe进程占用CPU100%
- php 随机记录mysql rand()造成CPU 100%的解决办法
- 为什么说log file sync(其实是写redo慢)会造成buffer busy wait?