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  %utilsda               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.00sdb               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.03dm-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.00dm-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.00dm-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//io 中看到:

# cat /proc/3088/iorchar: 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//io 中的原始数据计算单位时间内的增量:

# pidstat -d 2 2Linux 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  Command12:30:17 PM     0     14772   3362.25      0.00      0.00  dd12:30:17 PM   UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command12: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>    COMMAND14772 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 stapglobal device_of_interestprobe 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/sdbbrw-rw----. 1 root disk 8, 16 Oct 24 15:52 /dev/sdbMajor number(12-bit):  8 i.e. 0x8Minor number(20-bit): 16 i.e. 0x00010合在一起得到设备号:0x800010

执行脚本,我们看到:

# ./dev_task_io.stp 0x800010device 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进行读操作。

来源:http://linuxperf.com/?p=40

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. asynchronous aof fsync is taking too long (disk is busy?)

    一.背景 线上redis的监控数据不太好看,领导觉得看看能不能优化下,分析下什么情况,于是就..... 二.现象 看到redis日志里面一堆这个,于是就开始了分析排查 先放一张前后对比图吧 三.排查 ...

  4. Redis源码分析:AOF策略与时间触发任务

    时间周期性任务与AOF策略 周期性任务在分析启动流程与服务端处理的过程的时候,描述过有关时间任务的处理过程,在Redis内部事件驱动的过程中,有通过时间来进行事件的触发与处理机制,本文会先分析一下主要 ...

  5. 当 Redis 发生高延迟时,到底发生了什么

    来自:程序员厉小冰 Redis 是一种内存数据库,将数据保存在内存中,读写效率要比传统的将数据保存在磁盘上的数据库要快很多.但是 Redis 也会发生延迟时,这是就需要我们对其产生原因有深刻的了解,以 ...

  6. 深入学习Redis持久化

    一.Redis高可用概述 在介绍Redis高可用之前,先说明一下在Redis的语境中高可用的含义. 我们知道,在web服务器中,高可用是指服务器可以正常访问的时间,衡量的标准是在多长时间内可以提供正常 ...

  7. PostgreSQL 异步IO实测

    标签 PostgreSQL , effective_io_concurrency , 异步IO 背景 异步IO的目的是充分发挥块设备的吞吐能力,让块设备处于更繁忙的工作状态(一次连续摄取更多的块),而 ...

  8. windows 系统监视器 以及建议阀值

    常用的windows计数器及性能分析方法 一.常用的windows计数器 processor %processor time    建议阈值85% memory Available bytes    ...

  9. Redis数据持久化机制AOF原理分析一---转

    http://blog.csdn.net/acceptedxukai/article/details/18136903 http://blog.csdn.net/acceptedxukai/artic ...

  10. Redis 高可用特性之 “持久化” 详解

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

最新文章

  1. 2018-3-21李宏毅机器学习笔记十一-----Brief Introduction of Deep Learning?
  2. 照葫芦画瓢-python editors(编辑器 IDE)
  3. yii2事务运用举例
  4. 云原生应用程序运行时 Kyma 简介
  5. JavaScript实现快速排序
  6. Linux跑齿轮命令,【转】glxgears命令
  7. java同样作用的方法_Java的接口用途和方法
  8. 红魔游戏手机6 Pro氘锋透明版明日开启预售:售价5599元
  9. 消息中间件学习总结(4)——RocketMQ之RocketMQ 迈入50万TPS消息俱乐部
  10. GDI+处理带透明区域的png图片
  11. 面试回忆之四:所投职位和背景极端不匹配的简历
  12. Windows安装Java8以及环境变量的配置(图解以及java安装包下载)
  13. python导入包如果找不到
  14. IIS6/IIS7以上、Nginx、Apache拦截屏蔽垃圾蜘蛛UA爬行降低负载方法IIS7.5如何限制某UserAgent 禁止访问
  15. 人生,关了一扇窗,又开启另一扇门
  16. Windows 10 资源管理器使用深色主题
  17. React之Ref如何去使用?
  18. 【无标题】西门子S7-200SMART四种密码解密软件
  19. eclipse设置代码格式化(详解)
  20. 公路车sava和Java_入门之作 意外惊喜 SAVA追风5.0公路车 评测

热门文章

  1. 怎么通过$a获取到$b?某豹面试题
  2. c#开发Mongo笔记第九篇
  3. 为开发用途mac电脑瘦身
  4. 编程之美之寻找发帖“水王” 的算法问题
  5. 【转】Unix的文件系统的内部结构,主要是超级块、inode相关知识
  6. I/O多路复用通信连接select篇
  7. 国人项目上了Github全球热榜,之后都发生了什么?
  8. hdu 4315 Climbing the Hill 博弈问题,可转化为nim游戏问题,多校联合赛(二)第六题
  9. 解决Mac网络连接问题的一些方法
  10. 在Mac端的 几种文本操作技巧