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进行读操作。

原文链接

DISK 100% BUSY,谁造成的?的更多相关文章

  1. Linux disk 100% busy,谁造成的?

    disk 100% busy,谁造成的? 2016/11/16 vmunix iostat等命令看到的是系统级的统计,比如下例中我们看到/dev/sdb很忙,如果要追查是哪个进程导致的I/O繁忙,应该 ...

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

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

  3. Redis 5种数据结构使用及注意事项

    1优缺点 非常非常的快,有测评说比Memcached还快(当大家都是单CPU的时候),而且是无短板的快,读写都一般的快,所有API都差不多快,也没有MySQL Cluster.MongoDB那样更新同 ...

  4. 深入剖析 redis AOF 持久化策略

    本篇主要讲的是 AOF 持久化,了解 AOF 的数据组织方式和运作机制.redis 主要在 aof.c 中实现 AOF 的操作. 数据结构 rio redis AOF 持久化同样借助了 struct ...

  5. 关于Redis的常识(推荐)

    原文出处: https://github.com/springside/springside4/wiki/redis 版本:V3.0.3 2013-8-1 (@江南白衣版权所有,转载请保留出处) 1. ...

  6. 关于Redis的知识汇总[转]

    1. Overview 1.1 资料 <The Little Redis Book> ,最好的入门小册子,可以先于一切文档之前看,免费. 作者Antirez的博客,Antirez维护的Re ...

  7. 【OS】NMON的简介和使用

    [OS]NMON的简介和使用 目前NMON已开源,以sourceforge为根据地,网址是http://nmon.sourceforge.net. 1. 目的 本文介绍操作系统监控工具Nmon的概念. ...

  8. 深入学习Redis(2):持久化

    前言 在上一篇文章中,介绍了Redis的内存模型,从这篇文章开始,将依次介绍Redis高可用相关的知识——持久化.复制(及读写分离).哨兵.以及集群. 本文将先说明上述几种技术分别解决了Redis高可 ...

  9. 深入Redis持久化

    转载:https://segmentfault.com/a/1190000017193732 一.Redis高可用概述 在介绍Redis高可用之前,先说明一下在Redis的语境中高可用的含义. 我们知 ...

随机推荐

  1. caffe源码阅读(一)convert_imageset.cpp注释

    PS:本系列为本人初步学习caffe所记,由于理解尚浅,其中多有不足之处和错误之处,有待改正. 一.实现方法 首先,将文件名与它对应的标签用 std::pair 存储起来,其中first存储文件名,s ...

  2. 深入理解JavaScript系列

    转自http://www.cnblogs.com/TomXu/archive/2011/12/15/2288411.html 深入理解JavaScript系列(1):编写高质量JavaScript代码 ...

  3. php限定时间内同一ip只能访问一次

    建立一个数据表 CREATE TABLE `clicks` ( `ip` INT UNSIGNED NOT NULL , `time1` INT UNSIGNED NOT NULL , `time2` ...

  4. SQL 查询所有表名、字段名、类型、长度、存储过程、视图

    -- 获得存储过程创建语句 select o.xtype,o.name,cm.text from syscomments cm inner join sysobjects o on o.id=cm.i ...

  5. iOS点击状态栏返回顶部问题。

    在适配点击状态栏返回顶部的时候,有一个viewcontroller里面有一个UITableView和一个UITextView,UITableView的cell里面没有UIScrollView和UITa ...

  6. js 赋值 要用 toString() ; 太坑了。

    js 赋值 要用 toString() ;     太坑了. js 赋值 要用 toString() ;     太坑了. js 赋值 要用 toString() ;     太坑了.

  7. Slyx_SerAddGet

    ##通道##119.29.192.206:12002## ##通道##58.221.49.24:12002##

  8. 控制台telnet连接后无法关闭

    按下ctrl+]然后再quit就可以close connection

  9. location对象

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/ ...

  10. Python3

    1.上节内容回顾 递归: 明确的结束条件 问题规模每递归一次都应该比上一次的问题规模有所减少 效率低 高阶函数 文件: rb.wb.ab 一般用在不同系统之间传数据,和传视频流的时候用到,一般以这种形 ...