在CentOS系统中跟踪高IO等待
时间:2015-04-12 13:45 来源:lvtao.net 作者:吕滔博客
高IO等待问题的第一个征兆通常是系统平均负载。负载均衡的计算都是基于CPU利用率的，即使用或等待CPU的进程数目，当然，在Linux平台上，进程 几乎都处于不可中断的睡眠状态。负载均衡的基线可以解释为，在一个CPU核的机器上上，该CPU得到充分利用。因此，对于4核机器中，如果系统平均复杂为 4，表示该机器有足够的资源来处理它需要做的工作，当然只是勉强。在相同的4核系统，如果平均复杂是8，那么以为这将意味着服务器系统需要8个core才 能处理所要做的工作，但现在只有4个核，所以已经超载。
如果系统显示平均负载较高，但是CPU的系统(system)和用户(user)利用率较低，那么就需要观察IO 等待(即IO wait)。在linuc系统上，IO wait对系统负载有较大的影响，主要因为一个或多个核都可能被磁盘IO或网络IO所阻塞，只有当磁盘IO或网络IO完成后，这些核上的任务(即进程)才 能进行下去。而这些进程使用ps aux来查看均处于”D”状态，即不可中断的睡眠状态。
发现进程在等待IO完成是一回事，验证高IO wait的原因是另一回事。使用”iostat –x 1”能够显示正在使用的物理存储设备的IO情况：
[username@server~]$ iostat -x 1
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
cciss/c0d0 0.08 5.94 1.28 2.75 17.34 69.52 21.60 0.11 26.82 4.12 1.66
cciss/c0d0p1 0.00 0.00 0.00 0.00 0.00 0.00 5.30 0.00 8.76 5.98 0.00
cciss/c0d0p2 0.00 0.00 0.00 0.00 0.00 0.00 58.45 0.00 7.79 3.21 0.00
cciss/c0d0p3 0.08 5.94 1.28 2.75 17.34 69.52 21.60 0.11 26.82 4.12 1.66
由上可知，很明显，设备/dev/cciss/c0d0p3的等待时间很长。然而，我们并没有挂载找个设备，实际上，它是个LVM设备。如果您使用的是 LVM作为存储，那么，您应该发现iostat应该有那么一点混乱。LVM使用device mapper子系统将文件系统映射到物理设备，因此，iostat可能显示多个设备，比如/ dev/dm-0和/ dev/dm-1。而”df –h”的输出却不会显示device mapper路径，而是打印了LVM路径。最简单的方法是在iostat参数中添加选项”-N”。
[username@server~]$ iostat -xN 1
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
vg1-root 0.00 0.00 0.09 3.01 0.85 24.08 8.05 0.08 24.69 1.79 0.55
vg1-home 0.00 0.00 0.05 1.46 0.97 11.69 8.36 0.03 19.89 3.76 0.57
vg1-opt 0.00 0.00 0.03 1.56 0.46 12.48 8.12 0.05 29.89 3.53 0.56
vg1-tmp 0.00 0.00 0.00 0.06 0.00 0.45 8.00 0.00 24.85 4.90 0.03
vg1-usr 0.00 0.00 0.63 1.41 5.85 11.28 8.38 0.07 32.48 3.11 0.63
vg1-var 0.00 0.00 0.55 1.19 9.21 9.54 10.74 0.04 24.10 4.24 0.74
vg1-swaplv 0.00 0.00 0.00 0.00 0.00 0.00 8.00 0.00 3.98 1.88 0.00
为简便起见，裁剪上面iostat命令的输出信息。列出的每个文件系统所显示出的IO等待都是不可接受的，观察第十栏标有“await”的数据。相比而 言，文件系统/usr的await时间要高一些。我们先来分析一下这个文件系统，使用命令” fuser -vm /opt ”查看哪些进程在访问这个文件系统，进程列表如下。
root@server:/root > fuser -vm /opt
USER PID ACCESS COMMAND
/opt: db2fenc1 1067 ....m db2fmp
db2fenc1 1071 ....m db2fmp
db2fenc1 2560 ....m db2fmp
db2fenc1 5221 ....m db2fmp
当前服务器上有112个DB2进程正在访问/opt文件系统，为简便起见，列出四项。看来已经找到导致问题的原因，在服务器上，数据库配置为可使用速度更快的SAN访问，操作系统可以使用的是本地磁盘。可以打电话问问DBA(数据库管理员)怎么做才能这样配置。
最后一个组要的注意的是LVM和device mapper。 “Iostat –xN”命令的输出显示的是逻辑卷名，但它是可以通过命令”ls –lrt / dev /mapper”查到映射关系表。输出信息的第六列中的dm-是与iostat中的设备名相对应的。
有时候，在操作系统或应用层是没有什么可以做的，除了选择速度更快的磁盘，并没有其他的选择。幸运的是，快速磁盘访问，如SAN或SSD的价格正在逐步下降。
(责任编辑：IT)
| 高IO等待问题的第一个征兆通常是系统平均负载。负载均衡的计算都是基于CPU利用率的，即使用或等待CPU的进程数目，当然，在Linux平台上，进程 几乎都处于不可中断的睡眠状态。负载均衡的基线可以解释为，在一个CPU核的机器上上，该CPU得到充分利用。因此，对于4核机器中，如果系统平均复杂为 4，表示该机器有足够的资源来处理它需要做的工作，当然只是勉强。在相同的4核系统，如果平均复杂是8，那么以为这将意味着服务器系统需要8个core才 能处理所要做的工作，但现在只有4个核，所以已经超载。 如果系统显示平均负载较高，但是CPU的系统(system)和用户(user)利用率较低，那么就需要观察IO 等待(即IO wait)。在linuc系统上，IO wait对系统负载有较大的影响，主要因为一个或多个核都可能被磁盘IO或网络IO所阻塞，只有当磁盘IO或网络IO完成后，这些核上的任务(即进程)才 能进行下去。而这些进程使用ps aux来查看均处于”D”状态，即不可中断的睡眠状态。 发现进程在等待IO完成是一回事，验证高IO wait的原因是另一回事。使用”iostat –x 1”能够显示正在使用的物理存储设备的IO情况： [username@server~]$ iostat -x 1 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util cciss/c0d0 0.08 5.94 1.28 2.75 17.34 69.52 21.60 0.11 26.82 4.12 1.66 cciss/c0d0p1 0.00 0.00 0.00 0.00 0.00 0.00 5.30 0.00 8.76 5.98 0.00 cciss/c0d0p2 0.00 0.00 0.00 0.00 0.00 0.00 58.45 0.00 7.79 3.21 0.00 cciss/c0d0p3 0.08 5.94 1.28 2.75 17.34 69.52 21.60 0.11 26.82 4.12 1.66 由上可知，很明显，设备/dev/cciss/c0d0p3的等待时间很长。然而，我们并没有挂载找个设备，实际上，它是个LVM设备。如果您使用的是 LVM作为存储，那么，您应该发现iostat应该有那么一点混乱。LVM使用device mapper子系统将文件系统映射到物理设备，因此，iostat可能显示多个设备，比如/ dev/dm-0和/ dev/dm-1。而”df –h”的输出却不会显示device mapper路径，而是打印了LVM路径。最简单的方法是在iostat参数中添加选项”-N”。 [username@server~]$ iostat -xN 1 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util vg1-root 0.00 0.00 0.09 3.01 0.85 24.08 8.05 0.08 24.69 1.79 0.55 vg1-home 0.00 0.00 0.05 1.46 0.97 11.69 8.36 0.03 19.89 3.76 0.57 vg1-opt 0.00 0.00 0.03 1.56 0.46 12.48 8.12 0.05 29.89 3.53 0.56 vg1-tmp 0.00 0.00 0.00 0.06 0.00 0.45 8.00 0.00 24.85 4.90 0.03 vg1-usr 0.00 0.00 0.63 1.41 5.85 11.28 8.38 0.07 32.48 3.11 0.63 vg1-var 0.00 0.00 0.55 1.19 9.21 9.54 10.74 0.04 24.10 4.24 0.74 vg1-swaplv 0.00 0.00 0.00 0.00 0.00 0.00 8.00 0.00 3.98 1.88 0.00 为简便起见，裁剪上面iostat命令的输出信息。列出的每个文件系统所显示出的IO等待都是不可接受的，观察第十栏标有“await”的数据。相比而 言，文件系统/usr的await时间要高一些。我们先来分析一下这个文件系统，使用命令” fuser -vm /opt ”查看哪些进程在访问这个文件系统，进程列表如下。 root@server:/root > fuser -vm /opt USER PID ACCESS COMMAND /opt: db2fenc1 1067 ....m db2fmp db2fenc1 1071 ....m db2fmp db2fenc1 2560 ....m db2fmp db2fenc1 5221 ....m db2fmp 当前服务器上有112个DB2进程正在访问/opt文件系统，为简便起见，列出四项。看来已经找到导致问题的原因，在服务器上，数据库配置为可使用速度更快的SAN访问，操作系统可以使用的是本地磁盘。可以打电话问问DBA(数据库管理员)怎么做才能这样配置。 最后一个组要的注意的是LVM和device mapper。 “Iostat –xN”命令的输出显示的是逻辑卷名，但它是可以通过命令”ls –lrt / dev /mapper”查到映射关系表。输出信息的第六列中的dm-是与iostat中的设备名相对应的。 有时候，在操作系统或应用层是没有什么可以做的，除了选择速度更快的磁盘，并没有其他的选择。幸运的是，快速磁盘访问，如SAN或SSD的价格正在逐步下降。 (责任编辑：IT) |