disk 100% busy,谁造成的?

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
...
1
2
3
4
5
6
7
8
9
# 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;
...
};
1
2
3
4
5
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
1
2
3
4
5
6
7
8
# 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

1
2
3
4
5
6
7
8
# 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]
...
1
2
3
4
5
6
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)
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#! /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

1
2
3
4
5
6
# 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
[dd](31202) dev:0x800010 rw:0 size:512
...
1
2
3
4
5
6
7
8
# ./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
[dd](31202) dev:0x800010 rw:0 size:512
...

结果很令人满意,我们看到是进程号为31202的dd命令在对/dev/sdb进行读操作。

转载自:

linuxperf.com/?cat=11

Linux disk 100% busy,谁造成的?的更多相关文章

  1. DISK 100% BUSY,谁造成的?

    iostat等命令看到的是系统级的统计,如果要追查是哪个进程导致的I/O繁忙,应该怎么办? iostat等命令看到的是系统级的统计,比如下例中我们看到/dev/sdb很忙,如果要追查是哪个进程导致的I ...

  2. DISK 100% BUSY,谁造成的?(ok)

    iostat等命令看到的是系统级的统计,比如下例中我们看到/dev/sdb很忙,如果要追查是哪个进程导致的I/O繁忙,应该怎么办? # iostat -xd ... Device: rrqm/s wr ...

  3. Better Linux Disk Caching & Performance with vm.dirty_ratio & vm.dirty_background_ratio

    In previous posts on vm.swappiness and using RAM disks we talked about how the memory on a Linux gue ...

  4. Linux经典100题及参考答案

    转至:https://blog.csdn.net/yaoqiang2011/article/details/11908189 一.单选题 1. cron 后台常驻程序 (daemon) 用于: A. ...

  5. Linux CPU 100%, kill -9 杀不掉进程

    1: top 查看 >top -c 此时 我们使用kill -9 15003, 杀掉这个进程短暂的CPU降低几秒, 然后死灰复燃了, 又一个进程占了CPU 99% 2: 查看15003 进程状态 ...

  6. linux cpu 100% 脚本

    for i in `seq 1 $(cat /proc/cpuinfo |grep "physical id" |wc -l)`; do dd if=/dev/zero of=/d ...

  7. linux 磁盘100% 清理

    df -h  查看磁盘使用有一个vdb满了 df   -i 查看inode 使用率 显示文件大小: du -sh /* du参数: -a : 列出所有的文件与目录容量,因为默认仅统计目录下面的文件量而 ...

  8. 12 Useful “df” Commands to Check Disk Space in Linux

    On the internet you will find plenty of tools for checking disk space utilization in Linux. However, ...

  9. linux 操作

    正在运行的内核和系统信息 # uname -a # 获取内核版本(和BSD版本) # lsb_release -a # 显示任何 LSB 发行版版本信息 # cat /etc/SuSE-release ...

随机推荐

  1. JAVA堆,栈的区别,用AarrayList、LinkedList自定义栈

    大家都知道java模拟机在运行时要开辟空间所以它有特定的五个内存划分: 1.寄存器:    2.本地方法区:    3.方法区:    4.栈内存:    5.堆内存: 但是我们今天来注重讲一下栈和堆 ...

  2. jvm--工具

    jps (java process status) == ps / top 作用:显示所有运行中的java进程. jstat 作用:查看类装载,内存,垃圾收集,jit编译的信息. jinfo 作用:实 ...

  3. windows环境下如何搭建Consul+Ocelot

    下面的是markdown格式的文档,懒得排版了,有兴趣的话可以去github上看,有源码 Github:https://github.com/yuchengao0721/Consul-Ocelot.g ...

  4. interface Part2(定义接口)

    一. 在 C# 语言中,类之间的继承关系仅支持单重继承,而接口是为了实现多重继承关系设计的. 二. 一个类能同时实现多个接口,还能在实现接口的同时再继承其他类,并且接口之间也可以继承. 三. 无论是表 ...

  5. VBA For Each循环

    For Each循环用于为数组或集合中的每个元素执行语句或一组语句.For Each循环与For循环类似; 然而,For Each循环是为数组或组中的每个元素执行的. 因此,这种类型的循环中将不存在步 ...

  6. vue多页面项目搭建(vue-cli 4.0)

    1.创建vue项目 cmd命令执行 vue create app (app 自定义的项目名) 一般都会选择后者,自己配置一下自己需要的选项(空格为选中) 这是我个人需要的一些选项,路由Router.状 ...

  7. RocketMQ——角色与术语详解

    原文地址:http://jaskey.github.io/blog/2016/12/15/rocketmq-concept/ RocketMQ——角色与术语详解 2016-12-15 THU 15:4 ...

  8. 一语道破Java 11的ZGC为何如此高效

    GC是大部分现代语言内置的特性,Java 11 新加入的ZGC号称可以达到10ms 以下的 GC 停顿,本文作者对这一新功能进行了深入解析.同时还对还对这一新功能带来的其他可能性做了展望.ZGC是否可 ...

  9. VS代码自动排版

    1, ctrl+a 2, ctrl+k 3, ctrl+f

  10. 20.Vue中获取DOM元素和组件

    1.获取DOM元素和组件:this.$refs