未加星标

CentOS系统中跟踪高IO等待详解

字体大小 | |
[系统(linux) 所属分类 系统(linux) | 发布者 店小二04 | 时间 | 作者 红领巾 ] 0人收藏点击收藏

高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 wait的原因是另一回事。使用”iostat –x 1”能够显示正在使用的物理存储设备的IO情况:

[[email protected]~]$ 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”。

[[email protected]~]$ 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 ”查看哪些进程在访问这个文件系统,进程列表如下。

            [email protected]:/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的价格正在逐步下降。

本文系统(linux)相关术语:linux系统 鸟哥的linux私房菜 linux命令大全 linux操作系统

分页:12
转载请注明
本文标题:CentOS系统中跟踪高IO等待详解
本站链接:http://www.codesec.net/view/521317.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 系统(linux) | 评论(0) | 阅读(20)