linux wa%过高，iostat查看io状况 Posted 2020-10-13 maxiongying
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了linux wa%过高，iostat查看io状况相关的知识，希望对你有一定的参考价值。
命令总结：
1. top/vmstat 发现 wa%过高,vmstat b >1；
参考文章
1. 关于Linux ios
最近测试
架设Jboss 服务器，业务逻辑用Java C++ 处理，使用JNI 衔接。
本应用对CPU和硬盘第三非常敏感，因为有压缩解压和大量数据交互。起初作压力测试时，发现服务器各资源使用都有剩余，而点击率曲线波动却非常大，简单看似乎是应用程序有问题。
使用top查看Cpu各核的使用情况，发现一个非常诡异的现象：
1. 经常只有部分核是满载的，另外一部分基本空闲；
2. 在CPU满载时，%wa 的波动比较大，有时会占到较大比例。
所以，监控整个CPU时会发现CPU使用率不高，实际上任务总是分派到某个核上且导致对应核满载。无法有效使用CPU，其它
废话不多说，%wa 指CPU 等待磁盘写入完成的时间。莫非是磁盘忙，怎样证明是磁盘在忙？
首先看下%wa的解释：Percentage of time that the CPU or CPUs were idle during which the system had an outstanding disk I/O request.
起初用`lsof | less Jboss 处理上传文件会默认写入到/tmp 文件夹，然后再执行了一次拷贝到程序读取的目录。修改Jboss 配置直接写入到程序读写目录，性能没有本质上的改变。
关于CPU 使用波动大，我们也在程序内部加了很多计时器，发现某些模块在处理并发时会有响应时间很长的情况，这点证实了为什么点击率波动很大。
但此模块进行单进程串行测试时，每秒完成事务数是相当可观的。一个进程每秒完成的事务数都比当前测试点击率要高很多！使用多进程来测试此模块时，发现“进程数=核数”时效果最佳。于是在Java层控制同时进入此模块的数量，毕竟Java 是调用JNI 来使用此模块，使用全局锁来控制并发，最终结果没有想象的那么理想，但明显可以看出：通过控制并发数，能有效提高CPU 的使用率，点击率也上升了一些。
另外一个问题就是，CPU 会出现一会满载，一会空闲的情况，导致点击率曲线仍然波动大的问题。商讨后决定在C++ 代码中加入“释放CPU控制权”的逻辑，这样就在代码层来作了一个负载均衡。点击率波动的问题得到了好转，但点击率仍然不理想，预期瓶颈是网络而实际变成了CPU 。
优化了压缩解决的处理后，性能没有明显提升。这时我才想起%wa，我还没有进一步证明是磁盘的闲忙程度。使用了一些监控工具，诸如：vmstat 、sar 、dstat 、sysstat 没有发现对磁盘作非常详细的监控。最后试了下iostat ，搞定！
iostat的编译非常简单，就一个c文件，MakeFile里作者写了一句话“Cann‘t be simpler”。直接make install就在目录下生成了iostat iostat -cdDx 10 ` 。其中有一列“%b ”描述了磁盘的闲忙程序，简单直接。另外还有详细的磁盘IO读写数据，帮助里也解释得非常清楚。
再进行一次压力测试，拿着这份数据，已经绝对性的说明问题了。此时那些大牛把代码改了一下，性能立马就上去了，千兆网络直接成为系统瓶颈。并于Java的控制问题，改用Apache直接编译程序模块调用，完成变为可控，问题瞬间解决！
附上iostat的源码：
转自：http://hi.baidu.com/higkoo/blog/item/d4f7f822e7871cf8d6cae25e.html
2.iostat来对linux硬盘IO性能进行了解
以前一直不太会用这个参数。现在认真研究了一下iostat，因为刚好有台重要的服务器压力高,所以放上来分析一下.下面这台就是IO有压力过大的服务器平均队列长度(avgqu-sz)类似于单位时间里平均排队人的个数 I/O 操作率 (%util)类似于收款台前有人排队的时间比例。
3. linux lsof详解
lsof简介
lsof（list open files）是一个列出当前系统打开文件的工具。在linux环境下，任何事物都以文件的形式存在，通过文件不仅仅可以访问常规数据，还可以访问网络连接和硬件。所以如传输控制协议 (TCP) 和用户数据报协议 (UDP) 套接字等，系统在后台都为该应用程序分配了一个文件描述符，无论这个文件的本质如何，该文件描述符为应用程序与基础操作系统
lsof使用
lsof输出信息含义
在终端下输入lsof即可显示系统打开的文件，因为 lsof 需要访问核心内存和各种文件，所以必须以 root 用户的身份运行它才能够充分地发挥其功能。
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME init 1 root cwd DIR 3,3 1024 2 / init 1 root rtd DIR 3,3 1024 2 / init 1 root txt REG 3,3 38432 1763452 /sbin/init init 1 root mem REG 3,3 106114 1091620 /lib/libdl-2.6.so init 1 root mem REG 3,3 7560696 1091614 /lib/libc-2.6.so init 1 root mem REG 3,3 79460 1091669 /lib/libselinux.so.1 init 1 root mem REG 3,3 223280 1091668 /lib/libsepol.so.1 init 1 root mem REG 3,3 564136 1091607 /lib/ld-2.6.so init 1 root 10u FIFO 0,15 1309 /dev/initctl
每行显示一个打开的文件，若不指定条件默认将显示所有进程打开的所有文件。lsof输出各列信息的意义如下：
COMMAND：进程的名称 PID：进程标识符 USER：进程所有者 FD：文件描述符，应用程序通过文件描述符识别该文件。如cwd、txt等 TYPE：文件类型，如DIR、REG等 DEVICE：指定磁盘的名称 SIZE：文件的大小 NODE：索引节点（文件在磁盘上的标识） NAME：打开文件的确切名称
其中FD 列中的文件描述符cwd 值表示应用程序的当前工作
txt 类型的文件是程序代码，如应用程序二进制文件本身或共享库，如上列表中显示的 /sbin/init 程序。其次数值表示应用
程序的文件描述符，这是打开该文件时返回的一个整数。如上的最后一行文件/dev/initctl，其文件描述符为 10。u 表示该
文件被打开并处于读取/写入模式，而不是只读 ? 或只写 (w) 模式。同时还有大写 的W 表示该应用程序具有对整个文件的写
锁。该文件描述符用于确保每次只能打开一个应用程序实例。初始打开每个应用程序时，都具有三个文件描述符，从 0 到 2，
分别表示标准输入、输出和错误流。所以大多数应用程序所打开的文件的 FD 都是从 3 开始。
与 FD 列相比，Type 列则比较直观。文件和目录分别称为 REG 和 DIR。而CHR 和 BLK，分别表示字符和块设备；
或者 UNIX、FIFO 和 IPv4，分别表示 UNIX 域套接字、先进先出 (FIFO) 队列和网际协议 (IP) 套接字。
lsof常用参数
lsof 常见的用法是查找应用程序打开的文件的名称和数目。可用于查找出某个特定应用程序将日志
例如，linux限制了进程能够打开文件的数目。通常这个数值很大，所以不会产生问题，并且在需要时，应用程序可以请求更大的值（直到某
个上限）。如果你怀疑应用程序耗尽了文件描述符，那么可以使用 lsof 统计打开的文件数目，以进行验证。lsof语法格式是：
常用的参数列表：
lsof filename 显示打开指定文件的所有进程 lsof -a 表示两个参数都必须满足时才显示结果 lsof -c string 显示COMMAND列中包含指定字符的进程所有打开的文件 lsof -u username 显示所属user进程打开的文件 lsof -g gid 显示归属gid的进程情况 lsof +d /DIR/ 显示目录下被进程打开的文件 lsof +D /DIR/ 同上，但是会搜索目录下的所有目录，时间相对较长 lsof -d FD 显示指定文件描述符的进程 lsof -n 不将IP转换为hostname，缺省是不加上-n参数 lsof -i 用以显示符合条件的进程情况 lsof -i[46] [protocol][@hostname|hostaddr][:service|port] 46 --> IPv4 or IPv6 protocol --> TCP or UDP hostname --> Internet host name hostaddr --> IPv4地址 service --> /etc/service中的 service name (可以不只一个) port --> 端口号 (可以不只一个)
例如： 查看22端口现在运行的情况
# lsof -i :22 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME sshd 1409 root 3u IPv6 5678 TCP *:ssh (LISTEN)
查看所属root用户进程所打开的文件类型为txt的文件:
# lsof -a -u root -d txt COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME init 1 root txt REG 3,3 38432 1763452 /sbin/init mingetty 1632 root txt REG 3,3 14366 1763337 /sbin/mingetty mingetty 1633 root txt REG 3,3 14366 1763337 /sbin/mingetty mingetty 1634 root txt REG 3,3 14366 1763337 /sbin/mingetty mingetty 1635 root txt REG 3,3 14366 1763337 /sbin/mingetty mingetty 1636 root txt REG 3,3 14366 1763337 /sbin/mingetty mingetty 1637 root txt REG 3,3 14366 1763337 /sbin/mingetty kdm 1638 root txt REG 3,3 132548 1428194 /usr/bin/kdm X 1670 root txt REG 3,3 1716396 1428336 /usr/bin/Xorg kdm 1671 root txt REG 3,3 132548 1428194 /usr/bin/kdm startkde 2427 root txt REG 3,3 645408 1544195 /bin/bash ... ...
lsof使用实例
一、查找谁在使用文件系统
在卸载文件系统时，如果该文件系统中有任何打开的文件，操作通常将会失败。那么通过lsof可以找出那些进程在使用当前要卸载的文件系统，如下：
# lsof /GTES11/ COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME bash 4208 root cwd DIR 3,1 4096 2 /GTES11/ vim 4230 root cwd DIR 3,1 4096 2 /GTES11/
在这个示例中，用户root正在其/GTES11目录中进行一些操作。一个 bash是实例正在运行，并且它当前的目录为/GTES11，另一个则显示的是vim正在编辑/GTES11下的文件。要成功地卸载/GTES11，应该在通知用户以确保情况正常之后，中止这些进程。 这个示例说明了应用程序的当前工作目录非常重要，因为它仍保持着文件资源，并且可以防止文件系统被卸载。这就是为什么大部分守护进程（后台进程）将它们的目录更改为根目录、或服务特定的目录（如 sendmail 示例中的 /var/spool/mqueue）的原因，以避免该守护进程阻止卸载不相关的文件系统。
二、恢复删除的文件
当Linux计算机受到入侵时，常见的情况是日志文件被删除，以掩盖攻击者的踪迹。管理错误也可能导致意外删除重要的文件，比如在清理旧日志时，意外地删除了数据库
当进程打开了某个文件时，只要该进程保持打开该文件，即使将其删除，它依然存在于磁盘中。这意味着，进程并不知道文件已经被删除，它仍然可以向打开该文件时提供给它的文件描述符进行读取和写入。除了该进程之外，这个文件是不可见的，因为已经删除了其相应的目录索引节点。
在/proc 目录下，其中包含了反映内核和进程树的各种文件。/proc目录挂载的是在内存中所映射的一块区域，所以这些文件和目录并不存在于磁盘中，因此当我们对这些文件进行读取和写入时，实际上是在从内存中获取相关信息。大多数与 lsof 相关的信息都存储于以进程的 PID 命名的目录中，即 /proc/1234 中包含的是 PID 为 1234 的进程的信息。每个进程目录中存在着各种文件，它们可以使得应用程序简单地了解进程的内存空间、文件描述符列表、指向磁盘上的文件的符号链接和其他
当系统中的某个文件被意外地删除了，只要这个时候系统中还有进程正在访问该文件，那么我们就可以通过lsof从/proc目录下恢复该文件的内容。 假如由于误操作将/var/log/messages文件删除掉了，那么这时要将/var/log/messages文件恢复的方法如下：
首先使用lsof来查看当前是否有进程打开/var/logmessages文件，如下：
# lsof |grep /var/log/messages syslogd 1283 root 2w REG 3,3 5381017 1773647 /var/log/messages (deleted)
从上面的信息可以看到 PID 1283（syslogd）打开文件的文件描述符为 2。同时还可以看到/var/log/messages已经标记被删除了。因此我们可以在 /proc/1283/fd/2 （fd下的每个以数字命名的文件表示进程对应的文件描述符）中查看相应的信息，如下：
# head -n 10 /proc/1283/fd/2 Aug 4 13:50:15 holmes86 syslogd 1.4.1: restart. Aug 4 13:50:15 holmes86 kernel: klogd 1.4.1, log source = /proc/kmsg started. Aug 4 13:50:15 holmes86 kernel: Linux version 2.6.22.1-8 ([email protected] ) (gcc version 4.2.0) #1 SMP Wed Jul 18 11:18:32 EDT 2007 Aug 4 13:50:15 holmes86 kernel: BIOS-provided physical RAM map: Aug 4 13:50:15 holmes86 kernel: BIOS-e820: 0000000000000000 - 000000000009f000 (usable) Aug 4 13:50:15 holmes86 kernel: BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved) Aug 4 13:50:15 holmes86 kernel: BIOS-e820: 0000000000100000 - 000000001f7d3800 (usable) Aug 4 13:50:15 holmes86 kernel: BIOS-e820: 000000001f7d3800 - 0000000020000000 (reserved) Aug 4 13:50:15 holmes86 kernel: BIOS-e820: 00000000e0000000 - 00000000f0007000 (reserved) Aug 4 13:50:15 holmes86 kernel: BIOS-e820: 00000000f0008000 - 00000000f000c000 (reserved)
从上面的信息可以看出，查看 /proc/8663/fd/15 就可以得到所要恢复的数据。如果可以通过文件描述符查看相应的数据，那么就可以使用 I/O 重定向将其复制到文件中，如:
cat /proc/1283/fd/2 > /var/log/messages
对于许多应用程序，尤其是日志文件和数据库，这种恢复删除文件的方法非常有用。
4. Linux iostat监测IO状态[转]
Linux系统出现了性能问题，一般我们可以通过top、iostat、free、vmstat等命令 来查看初步定位问题。其中iostat可以给我们提供丰富的IO状态数据。
1. 基本使用
$iostat -d -k 1 10
参数 -d 表示，显示设备（磁盘）使用状态；-k某些使用block为单位的列强制使用Kilobytes为单位；1 10表示，数据显示每隔1秒刷新一次，共显示10次。
$iostat -d -k 1 10
tps ：该设备每秒的传输次数（Indicate the number of transfers per second that were issued to the device.）。“一次传输”意思是“一次I/O请求”。多个逻辑请求可能会被合并为“一次I/O请求”。“一次传输”请求的大小是未知的。
kB_read/s ：每秒从设备（drive expressed）读取的数据量；kB_wrtn/s ：每秒向设备（drive expressed）写入的数据量；kB_read ：读取的总数据量；kB_wrtn ：写入 的总数量数据量；这些单位都为Kilobytes。
上面的例子中，我们可以看到磁盘sda以及它的各个分区的统计数据，当时统计的磁盘总TPS是39.29，下面是各个分区的TPS。（因为是瞬间 值，所以总TPS并不严格等于各个分区TPS的总和）
2. -x 参数
使用-x参数我们可以获得更多统计信息。
iostat -d -x -k 1 10
rrqm/s ：每秒这个设备相关的读取请求有多少被Merge了（当系统调用需要读取数据的 时候，VFS将请求发到各个FS，如果FS发现不同的读取请求读取的是相同Block的数据，FS会将这个请求合并Merge）；wrqm/s：每秒这个 设备相关的写入请求有多少被Merge了。
rsec/s ：每秒读取的扇区数；wsec/ ： 每秒写入的扇区数。r/s ：The number of read requests that were issued to the device per second；w/s ：The number of write requests that were issued to the device per second；
await ：每一个IO请求的处理的平均时间（单位是微秒）。这里可以理解为IO的响应时 间，一般地系统IO响应时间应该低于5ms，如果大于10ms就比较大了。
%util ：在统计时间内所有处理IO时间，除以总共统计时间。例如，如果统计间隔1秒，该 设备有0.8秒在处理IO，而0.2秒闲置，那么该设备的%util = 0.8/1 = 80%，所以该参数暗示了设备的繁忙程度。一般地，如果该参数是100%表示设备已经接近满负荷运行了（当然如果是多磁盘，即使%util是100%，因 为磁盘的并发能力，所以磁盘使用未必就到了瓶颈）。
3. -c 参数
iostat还可以用来获取cpu部分状态值：
iostat -c 1 10
4. 常见用法
$iostat -d -k 1 10 #查看TPS和吞吐量信息
5. 实例分析
$$iostat -d -k 1 |grep sda10
上面看到，磁盘每秒传输次数平均约400；每秒磁盘读取约5MB，写入约1MB。
iostat -d -x -k 1
可以看到磁盘的平均响应时间<5ms，磁盘使用率>80。磁盘响应正常，但是已经很繁忙了。
参考文献：
Linux man iostat
How Linux iostat computes its results Linux iostat
http://blog.csdn.net/AE86_FC/archive/2010/02/03/5284112.aspx
最近要对分布式集群做一些性能测试 linux 笔 记 数 据 文件
5. 如何查看进程 IO 读写情况？
2009年08月26日 | 标签: linux , python | 作者： vpsee
Linux Kernel 2.6.20 以上的内核支持进程 IO 统计，可以用类似 iotop 这样的工具来监测每个进程对 IO 操作的情况，就像用 top 来实时查看进程内存、CPU 等占用情况那样。但是对于 2.6.20 以下的 Linux 内核版本就没那么幸运了，根据Stack Overflow 的这篇回帖
Kernel < 2.6.20
这个脚本的想法很简单，把 dmesg 的结果重定向到一个文件后再解析出来，每隔1秒钟打印一次进程 IO 读写的统计信息，执行这个脚本需要 root：
#!/usr/bin/python
# Monitoring per-process disk I/O activity
# written by http://www.vpsee.com
import sys, os, time, signal, re
class DiskIO:
def __init__(self, pname=None, pid=None, reads=0, writes=0):
self.pname = pname
self.pid = pid
self.reads = 0
self.writes = 0
def main():
argc = len(sys.argv)
if argc != 1:
print "usage: ./iotop"
sys.exit(0)
if os.getuid() != 0:
print "must be run as root"
sys.exit(0)
signal.signal(signal.SIGINT, signal_handler)
os.system(‘echo 1 > /proc/sys/vm/block_dump‘)
print "TASK PID READ WRITE"
while True:
os.system(‘dmesg -c > /tmp/diskio.log‘)
l = []
f = open(‘/tmp/diskio.log‘, ‘r‘)
line = f.readline()
while line:
m = re.match( ‘^(\S+)\((\d+)\): (READ|WRITE) block (\d+) on (\S+)‘, line)
if m != None:
if not l:
l.append(DiskIO(m.group(1), m.group(2)))
line = f.readline()
continue
found = False
for item in l:
if item.pid == m.group(2):
found = True
if m.group(3) == "READ":
item.reads = item.reads + 1
elif m.group(3) == "WRITE":
item.writes = item.writes + 1
if not found:
l.append(DiskIO(m.group(1), m.group(2)))
line = f.readline()
time.sleep(1)
for item in l:
print "%-10s %10s %10d %10d" % (item.pname, item.pid, item.reads, item.writes)
def signal_handler(signal, frame):
os.system(‘echo 0 > /proc/sys/vm/block_dump‘)
sys.exit(0)
if __name__=="__main__":
main()
Kernel >= 2.6.20
如果想用 iotop 来实时查看进程 IO 活动状况的话，需要下载和升级新内核（2.6.20 或以上版本）。编译新内核时需要打开 TASK_DELAY_ACCT 和 TASK_IO_ACCOUNTING 选项。解压内核后进入配置界面：
# tar jxvf linux-2.6.30.5.tar.bz2
# mv linux-2.6.30.5 /usr/src/
# cd /usr/src/linux-2.6.30.5
# make menuconfig
选择 Kernel hacking –> Collect scheduler debugging info 和 Collect scheduler statistics，保存内核后编译内核：
# make; make modules; make modules_install; make install
修改 grub，确认能正确启动新内核：
# vi /boot/grub/menu.lst
出了新内核外，iotop 还需要 Python 2.5 或以上才能运行，所以如果当前 Python 是 2.4 的话需要下载和安装最新的 Python 包。这里使用源代码编译安装：
# tar jxvf Python-2.6.2.tar.bz2
# cd Python-2.6.2
# ./configure
# make; make install
别忘了下载 setuptools：
# mv setuptools-0.6c9-py2.6.egg.sh setuptools-0.6c9-py2.6.egg
# sh setuptools-0.6c9-py2.6.egg
更多信息
如果想知道更多关于 block_dump 的信息，可以看看这篇监测 Linux 进程的实时 IO 情况
以上是关于linux wa%过高，iostat查看io状况的主要内容，如果未能解决你的问题，请参考以下文章
linux负载过高 排查方法及说明 附:Centos安装iostat
监控io性能/free命令/ps命令/查看网络状况/linux下抓包
如何查看Linux下进程的IO活动状况 00 Hey，Linux
解决linux cpu占用不高但是负载很高
找出导致Mysql机器IO过高的SQL
linux iowait过高怎么查
