如何找出Linux系统高IO的思路总结

前言

I/O Wait是一个需要使用高级的工具来debug问题原因，当然也有许多基本工具的高级用法。I/O wait的问题难以定位的原因是：因为我们有很多工具可以告诉你I/O 受限了，但是并没有告诉你具体是哪个进程引起的。

1. 如何确认，是否是I/O问题导致系统缓慢

确认是否是I/O导致的系统缓慢我们可以使用多个命令，但是，最简单的是unix的命令 top

# top

top - 14:31:20 up 35 min, 4 users, load average: 2.25, 1.74, 1.68

Tasks: 71 total, 1 running, 70 sleeping, 0 stopped, 0 zombie

Cpu(s): 2.3%us, 1.7%sy, 0.0%ni, 0.0%id, 96.0%wa, 0.0%hi, 0.0%si, 0.0%st

Mem: 245440k total, 241004k used, 4436k free, 496k buffers

Swap: 409596k total, 5436k used, 404160k free, 182812k cached

从CPU这行，可以发现CPU的io wait；这里是96.0%。越高就代表CPU用于io wait的资源越多。

2. 找出哪个磁盘正在被写入

上边的top命令从一个整体上说明了I/O wait，但是并没有说明是哪块磁盘影响的，想知道是哪块磁盘引发的问题，可以使用另外一个命令 iostat 命令

$ iostat -x 2 5

avg-cpu: %user %nice %system %iowait %steal %idle

  3.66 0.00 47.64 48.69 0.00 0.00

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 44.50 39.27 117.28 29.32 11220.94 13126.70 332.17 65.77 462.79 9.80 2274.71 7.60 111.41

dm-0 0.00 0.00 83.25 9.95 10515.18 4295.29 317.84 57.01 648.54 16.73 5935.79 11.48 107.02

dm-1 0.00 0.00 57.07 40.84 228.27 163.35 8.00 93.84 979.61 13.94 2329.08 10.93 107.02

iostat 会每2秒更新一次，一共打印5次信息， -x 的选项是打印出扩展信息

第一个iostat 报告会打印出系统最后一次启动后的统计信息，这也就是说，在多数情况下，第一个打印出来的信息应该被忽略，剩下的报告，都是基于上一次间隔的时间。举例子来说，这个命令会打印5次，第二次的报告是从第一次报告出来一个后的统计信息，第三次是基于第二次 ，依次类推

所以，一定记住：第一个忽略！

在上面的例子中，sda的%utilized 是111.41%，这个很好的说明了有进程正在写入到sda磁盘中。

除了%utilized 外，我们可以从iostat得到更加丰富的资源信息，例如每毫秒读写请求（rrqm/s &wrqm/s)），每秒读写的（(r/s &w/s)。在上边的例子中，我们的项目看起来正在读写非常多的信息。这个对我们查找相应的进程非常有用。

3. 找出导致高IO的进程

# iotop

Total DISK READ: 8.00 M/s | Total DISK WRITE: 20.36 M/s

  TID PRIO USER DISK READ DISK WRITE SWAPIN IO>COMMAND

15758 be/4 root 7.99 M/s 8.01 M/s 0.00 % 61.97 % bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp

最简单的方法就是用iotop找出哪个进程用了最多的存储资源，从上面可以看到是bonnie++。

iotop很好用，但是不是默认安装的。

如果没有iotop，下面的方式也可以让你有种方法缩小范围，尽快找到是哪个进程。

ps 命令对内存和CPU有一个统计，但是他没有对磁盘I/O的统计，虽然他没有显示磁盘I/O，但是它显示进行的状态，我们可以用来知道一个进程是否正在等待I/O

主要的进程状态有：

PROCESS STATE CODES

D uninterruptible sleep (usually IO)

R running or runnable (on run queue)

S interruptible sleep (waiting for an event to complete)

T stopped, either by a job control signal or because it is being traced.

W paging (not valid since the 2.6.xx kernel)

X dead (should never be seen)

Z defunct ("zombie") process, terminated but not reaped by its parent.

等待I/O的进程的状态一般是“uninterruptible sleep”，或者“D”，我们可以很容易的查找到正在等待I/O的进程

# for x in `seq 1 1 10`do ps -eo state,pid,cmd | grep "^D"echo "----"sleep 5done

D 248 [jbd2/dm-0-8]

D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp

----

D 22 [kswapd0]

D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp

----

D 22 [kswapd0]

D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp

----

D 22 [kswapd0]

D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp

----

D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp

上边的例子会循环的输出状态是D的进程，每5秒一次，一共10次

从输出我们可以知道 bonnie++ 的pid是16528 ，在waiting，bonnie++看起来就是我们想找到的进程，但是，只是从它的状态，我们没有办法证明就是bonnie++引起的I/O等待。

为了证明，我们可以可以查看/proc，每个进程目录下都有一个叫io的文件，里边保存这和iotop类似的信息。

# cat /proc/16528/io

rchar: 48752567

wchar: 549961789

syscr: 5967

syscw: 67138

read_bytes: 49020928

write_bytes: 549961728

cancelled_write_bytes: 0

read_bytes和write_bytes是这个进程从磁盘读写的字节，在这个例子中，bonnie++进程读取了46M的数据并且写入了524MB的数据到磁盘上。

4. 找出哪个文件正在被大量写入

lsof 命令可以展示一个进程打开的所有文件。从这个列表中，我们可以找到哪个文件被写入。

# lsof -p 16528

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME

bonnie++ 16528 root cwd DIR 252,0 4096 130597 /tmp

<truncated>

bonnie++ 16528 root 8u REG 252,0 501219328 131869 /tmp/Bonnie.16528

bonnie++ 16528 root 9u REG 252,0 501219328 131869 /tmp/Bonnie.16528

bonnie++ 16528 root 10u REG 252,0 501219328 131869 /tmp/Bonnie.16528

bonnie++ 16528 root 11u REG 252,0 501219328 131869 /tmp/Bonnie.16528

bonnie++ 16528 root 12u REG 252,0 501219328 131869 <strong>/tmp/Bonnie.16528</strong>

# df /tmp

Filesystem 1K-blocks Used Available Use% Mounted on

/dev/mapper/workstation-root 7667140 2628608 4653920 37% /

# pvdisplay

  --- Physical volume ---

  PV Name /dev/sda5

  VG Name workstation

  PV Size 7.76 GiB / not usable 2.00 MiB

  Allocatable yes

  PE Size 4.00 MiB

  Total PE 1986

  Free PE 8

  Allocated PE 1978

  PV UUID CLbABb-GcLB-l5z3-TCj3-IOK3-SQ2p-RDPW5S

使用pvdisplay可以看到，pv设备就是/dev/sda5,正是我们前面找到的sda。

参考文档：http://bencane.com/2012/08/06/troubleshooting-high-io-wait-in-linux/

在Linux下，我们使用ulimit-n命令可以看到单个进程能够打开的最大文件句柄数量(socket连接也算在里面)。系统默认值1024。对于一般的应用来说(象Apache、系统进程)1024完全足够使用。但是如何象squid、mysql、java等单进程处理大量请求的应用来说就有点捉襟见肘了。如果单个进程打开的文件句柄数量超过了系统定义的值，就会提到“toomanyfilesopen”的错误提示。如何知道当前进程打开了多少个文件句柄呢？下面一段小脚本可以帮你查看：lsof-n|awk'{print$2}'|sort|uniq-c|sort-nr|more在系统访问高峰时间以root用户执行上面的脚本，可能出现的结果如下：#lsof-n|awk'{print$2}'|sort|uniq-c|sort-nr|more13124204572424457242315624264其中第一行是打开的文件句柄数量，第二行是进程号。得到进程号后，我们可以通过ps命令得到进程的详细内容。ps-aef|grep24204mysql24204241629916:15?00:24:25/usr/sbin/mysqld哦，原来是mysql进程打开最多文件句柄数量。但是他目前只打开了131个文件句柄数量，远远底于系统默认值1024。但是如果系统并发特别大，尤其是squid服务器，很有可能会超过1024。这时候就必须要调整系统参数，以适应应用变化。Linux有硬性限制和软性限制。可以通过ulimit来设定这两个参数。方法如下，以root用户运行以下命令：ulimit-HSn4096以上命令中，H指定了硬性大小，S指定了软性大小，n表示设定单个进程最大的打开文件句柄数量。个人觉得最好不要超过4096，毕竟打开的文件句柄数越多响应时间肯定会越慢。设定句柄数量后，系统重启后，又会恢复默认值。如果想永久保存下来，可以修改.bash_profile文件，可以修改/etc/profile把上面命令加到最后。

使用iotop命令

使用该命令有个条件，Linux内核要高于2.6.20的版本，版本过低则没有此命令，执行效果如下图所示：

2：block_dump方法

首先，关闭syslog服务，然后开启block_dump，最后正则表达式提取dmesg信息。

/etc/init.d/syslog stop                    

echo 1 >/proc/sys/vm/block_dump

dmesg | egrep "READ|WRITE|dirtied" | egrep -o '([a-zA-Z]*)' | sort | uniq -c | sort -rn | head

执行结果如下图所示：

注意： *** 作完成后请关闭block_dump和启动syslog

echo 0 >/proc/sys/vm/block_dump       #关闭block_dump

/etc/init.d/syslog start                             #启动syslog

深入学习linux建议读《linux就该这么学》这本书

---