通过分析mpstat的iowait和iostat的util%,判断IO瓶颈

IO瓶颈往往是我们可能会忽略的地方(我们常会看top、free、netstat等等,但经常会忽略IO的负载情况),今天给大家详细分享一下如何确认一台服务器的IO负载是否到达了瓶颈,以及可能优化、定位的点。

mpstat中看CPU的iowait高了,难道IO就瓶颈了吗???

先来看一台典型的IO密集型服务器的cpu统计图:

可以看到,CPU总使用率不高,平均1.3%,max到5.6%,虽然大部分都耗在了iowait上,但才百分之五左右,应该还没到瓶颈吧???

错了!这里要特别注意:iowait≠IO负载,要看真实的IO负载情况,一般使用iostat –x 命令:

你会发现iowait虽然只有5%,但是iostat中看到util% 却到达99%,说明磁盘就没有闲着!!!

$ iostat –x 1
avg-cpu: %user %nice %system %iowait %steal %idle
0.04 0.00 0.04 4.99 0.00 94.92 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 81.00 104.00 4.00 13760.00 680.00 133.70 2.08 19.29 9.25 99.90
sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda5 0.00 81.00 104.00 4.00 13760.00 680.00 133.70 2.08 19.29 9.25 99.90

这里重点指标是svctm和util这两列,man一下可以看到如下解释:

svctm
The average service time (in milliseconds) for I/O requests that were issued to the device.
%util
Percentage of CPU time during which I/O requests were issued to the device (bandwidth utilization for the device). Device saturation occurs when this value is close to 100%.

svctm

可以看到,svctm指的是“平均每次设备I/O操作的服务时间 (毫秒)”,而util指的是“一秒中I/O 操作的利用率,或者说一秒中有多少时间 I/O 队列是非空的。”

util%

我们这里发现util已经接近100%,结合man的说明“Device saturation occurs when this value is close to 100%”可以知道其实目前这台服务器的IO已经到达瓶颈了。

那为什么最前面的cpu统计图的iowait项只有5.5%左右呢?因为这个iowait(也就是top里的wa%)指的是从整体来看,CPU等待IO的耗时占比:

wa -- iowait

Amount of time the CPU has been waiting for I/O to complete.

也就是说,CPU可能拿出一部分时间来等待IO完成(iowait),但从磁盘的角度看,磁盘的利用率已经满了(util%),这种情况下,CPU使用率可能不高,但是系统整体QPS已经上不去了,如果加大流量,会导致单次IO耗时的继续增加(因为IO请求都堵在队列里了),从而影响系统整体的处理性能。

确认了IO负载过高后,可以使用iotop工具具体查看IO负载主要是落在哪个进程上了。

那如何规避IO负载过高的问题呢?具体问题具体分析:

  1. 如果你的服务器用来做日志分析,要避免多个crontab交叠执行导致多进程随机IO(参考:随机IO vs 顺序IO),避免定期的压缩、解压大日志(这种任务会造成某段时间的IO抖动)。
  2. 如果是前端应用服务器,要避免程序频繁打本地日志、或者异常日志等。
  3. 如果是存储服务(mysql、nosql),尽量将服务部署在单独的节点上,不要和其它服务共用,甚至服务本身做读写分离以降低读写压力;调优一些buffer参数以降低IO写的频率等等。另外还可以参考LevelDB这种将随机IO变顺序IO的经典方式。

通过vmstat和iostat,判断IO瓶颈

oot@localhost ~]# vmstat -n 3       (每个3秒刷新一次)
procs-----------memory--------------------swap--- ---io---- --system---- ------cpu--------
r b swpd free buff cache si so bi bo in cs us sy id wa
1 0 144 186164 105252 2386848 0 0 18 166 83 2 48 21 31 0
2 0 144 189620 105252 2386848 0 0 0 177 1039 1210 34 10 56 0
0 0 144 214324 105252 2386848 0 0 0 10 1071 670 32 5 63 0
0 0 144 202212 105252 2386848 0 0 0 189 1035 558 20 3 77 0
2 0 144 158772 105252 2386848 0 0 0 203 1065 2832 70 14 15

IO

-bi:从块设备读入的数据总量(读磁盘)(KB/S)

-bo:写入到块设备的数据总量(写磁盘)(KB/S)

随机磁盘读写的时候,这2个值越大(如超出1M),能看到CPU在IO等待的值也会越大

iostat 实现

程序代码

iostat [ -c | -d ] [ -k ] [ -t ] [ -V ] [ -x [ device ] ] [ interval [ count ] ]

-c为汇报CPU的使用情况;

-d为汇报磁盘的使用情况;

-k表示每秒按kilobytes字节显示数据;

-t为打印汇报的时间;

-v表示打印出版本信息和用法;

-x device指定要统计的设备名称,默认为所有的设备;

interval指每次统计间隔的时间;

count指按照这个时间间隔统计的次数。

iostat在内核2.4和内核2.6中数据来源不太一样,对于kernel 2.4, iostat 的数据的主要来源是 /proc/partitions;在2.6中,数据来源主要是/proc/diskstats和/sys/block/sd*/stat这两个文件

#cat /proc/diskstats | grep sda
8 0 sda 17945521 1547188 466667211 174042714 15853874 42776252 469241932 2406054445 0 137655809 2580960422
8 1 sda1 936 1876 6 12
8 2 sda2 19489178 466659986 58655070 469240224
8 3 sda3 1270 1441 33 264
8 4 sda4 4 8 0 0
8 5 sda5 648 1442 0 0
8 6 sda6 648 1442 0 0
第1列 : 磁盘主设备号(major)
第2列 : 磁盘次设备号(minor)
第3列 : 磁盘的设备名(name)
第4列 : 读请求总数(rio)
第5列 : 合并的读请求总数(rmerge)
第6列 : 读扇区总数(rsect)
第7列 : 读数据花费的时间,单位是ms.(从__make_request到 end_that_request_last)(ruse)
第8列 : 写请求总数(wio)
第9列 : 合并的写请求总数(wmerge)
第10列 : 写扇区总数(wsect)
第11列 : 写数据花费的时间,单位是ms. (从__make_request到 end_that_request_last)(wuse)
第12列 : 现在正在进行的I/O数(running),等于I/O队列中请求数
第13列 : 系统真正花费在I/O上的时间,除去重复等待时间(aveq)
第14列 : 系统在I/O上花费的时间(use)。
#iostat -x 1
Linux 2.6.18-53.el5PAE (localhost.localdomain) 03/27/2009
avg-cpu: %user %nice %system %iowait %steal %idle
30.72 0.00 5.00 5.72 0.00 58.56
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 0.79 21.81 9.15 8.08 237.99 239.29 27.69 1.32 76.31 4.07 7.02
sdb 0.69 19.13 3.26 2.99 153.08 176.92 52.85 0.43 68.80 5.96 3.72
sdc 3.47 89.30 10.95 7.30 213.30 772.94 54.04 1.32 72.43 4.18 7.63

每项数据的含义如下,

rrqm/s:     每秒进行 merge 的读操作数目。即 rmerge/s
wrqm/s: 每秒进行 merge 的写操作数目。即 wmerge/s
r/s: 每秒完成的读 I/O 设备次数。即 rio/s
w/s: 每秒完成的写 I/O 设备次数。即 wio/s
rsec/s: 每秒读扇区数。即 rsect/s
wsec/s: 每秒写扇区数。即 wsect/s
rkB/s: 每秒读K字节数。是 rsect/s 的一半,因为每扇区大小为512字节。
wkB/s: 每秒写K字节数。是 wsect/s 的一半。
avgrq-sz: 平均每次设备I/O操作的数据大小 (扇区)。即 (rsect+wsect)/(rio+wio)
avgqu-sz: 平均I/O队列长度。即 aveq/1000 (因为aveq的单位为毫秒)。
await: 平均每次设备I/O操作的等待时间 (毫秒)。即 (ruse+wuse)/(rio+wio)
svctm: 平均每次设备I/O操作的服务时间 (毫秒)。即 use/(rio+wio)
%util: 一秒中有百分之多少的时间用于 I/O 操作,或者说一秒中有多少时间
I/O队列是非空的,即use/1000 (因为use的单位为毫秒),
如果 %util 接近 100%,说明产生的I/O请求太多,I/O系统已经满负荷,该磁盘可能存在瓶颈。

svctm 一般要小于 await (因为同时等待的请求的等待时间被重复计算了),

svctm 的大小一般和磁盘性能有关,CPU/内存的负荷也会对其有影响,请求过多

也会间接导致 svctm 的增加。

await 的大小一般取决于服务时间(svctm) 以及 I/O 队列的长度和 I/O 请求的发出模式。如果 svctm 比较接近 await,说明 I/O 几乎没有等待时间;如果 await 远大于 svctm,说明 I/O 队列太长,应用得到的响应时间变慢,如果响应时间超过了用户可以容许的范围,这时可以考虑更换更快的磁盘,调整内核 elevator 算法,优化应用,或者升级 CPU。

队列长度(avgqu-sz)也可作为衡量系统 I/O 负荷的指标,但由于 avgqu-sz 是按照单位时间的平均值,所以不能反映瞬间的 I/O 洪水。

io/s = r/s +w/s

await=(ruse+wuse)/io(每个请求的等待时间)

awaitio/s=每秒内的I/O请求总共需要等待的ms

avgqu-sz=await
(r/s+w/s)/1000 (队列长度)

以下数据其实与/proc/diskstats中除设备号与设备名外的其它数据是一一对应关系,只是统计的方法略有差别而已。

#cat /sys/block/sda/stat
17949157 1547772 466744707 174070520 15855905 42781288 469298468 2406092114 2 137680700 2581025934

定位IO瓶颈的方法,iowait低,IO就没有到瓶颈?的更多相关文章

  1. linux系统瓶颈分析(精) CPU Memory IO Network

    linux系统瓶颈分析(精) linux系统瓶颈分析(精) (2013-09-17 14:22:00)   分类: linux服务器瓶颈分析 1.0 性能监控介绍性能优化就是找到系统处理中的瓶颈以及去 ...

  2. linux下测试磁盘的读写IO速度-简易方法

    linux下测试磁盘的读写IO速度-简易方法 参考资料:https://blog.csdn.net/zqtsx/article/details/25487185 一:使用hdparm命令 这是一个是用 ...

  3. Java.io下的方法是对磁盘上的文件进行磁盘操作

    File类(java.io.*)可表示一个文件,也有可能是一个目录(在JAVA中文件和目录都属于这个类中,而且区分不是非常的明显). Java.io下的方法是对磁盘上的文件进行磁盘操作,但是无法读取文 ...

  4. Java.io.ObjectOutputStream.writeObject()方法实例

    java.io.ObjectOutputStream.writeObject(Object obj) 方法将指定对象写入ObjectOutputStream.该对象的类,类的签名,以及类及其所有超类型 ...

  5. python开发IO模型:阻塞&非阻塞&异步IO&多路复用&selectors

    一 IO模型介绍 为了更好地了解IO模型,我们需要事先回顾下:同步.异步.阻塞.非阻塞 同步(synchronous) IO和异步(asynchronous) IO,阻塞(blocking) IO和非 ...

  6. Android日志打印类LogUtils,能够定位到类名,方法名以及出现错误的行数并保存日志文件

    Android日志打印类LogUtils,能够定位到类名,方法名以及出现错误的行数并保存日志文件 在开发中,我们常常用打印log的方式来调试我们的应用.在Java中我们常常使用方法System.out ...

  7. 文件IO 相关的包:java.io文件——API

    文件IO 相关的包:java.io文件——API 1.Java.io.File类的使用(1)两种路径绝对路径:相对于当前路径:当前为 “工程名”(2)File类创建,对象为一个文件/目录,可能存在或不 ...

  8. linux基础编程:IO模型:阻塞/非阻塞/IO复用 同步/异步 Select/Epoll/AIO(转载)

      IO概念 Linux的内核将所有外部设备都可以看做一个文件来操作.那么我们对与外部设备的操作都可以看做对文件进行操作.我们对一个文件的读写,都通过调用内核提供的系统调用:内核给我们返回一个file ...

  9. Scalable IO in Java【java高效IO】

    第一次翻译,如有错误,请指正 1.Outline 大纲Scalable network services  高效网络服务 Event-driven processing  事件驱动处理 Reactor ...

  10. python IO模式(多路复用和异步IO深入理解)

    1.事件渠道模型.事件渠道为异步IO的原型. 2.IO模式,一次IO调用会经历两个阶段.一.等待数据阶段,将数据从网络或者是磁盘读取到系统内核(kennel) 二.将数据从内核拷贝到进程中. 基于这两 ...

随机推荐

  1. SSH框架之Struts(3)——Struts的执行流程之核心方法

    上篇讲了Tomcat实例化一个单例的ActionServlet.依据web.xml配置文件做好对应的初始化工作. 这时client产生一个.do结尾的request请求,採用get/post方式提交之 ...

  2. CF #329 D

    D题,LCA是很明显的.要注意的是,因为是除法,所以最多可以除x>2的有64次,当大于64时可以直接返回0.而且注意到可能会有很多值为1的边,可以使用路径压缩,把边为1的边压缩掉,类似于并查集的 ...

  3. D. Multiplication Table 二分查找

    刚做这道题根本没想到二分,最关键是没想出来怎样统计在这个矩阵中比一个数小的有几个怎么算.造成自己想了好久最后看了别人的提示才做出来.哎.好久不做题太弱了 #include<iostream> ...

  4. apache storm 的安装

    原文: http://storm.praveendeshmane.co.in/storm/storm-0-10-0-installation-on-ubuntu-14-04.jsp --------- ...

  5. 翻翻git之---自己定义邮件发送buttonSendButton(流程分析,实现思路能够学习下)

    转载请注明出处:王亟亟的大牛之路 距离过春节还有1天.继续这一系列的git翻料之旅. 昨天的工具类真的非常棒,这里再推崇一下 传送门:http://blog.csdn.net/ddwhan0123/a ...

  6. Git使用SSH提交代码到server出现 permission denied (publickey).

    在GitBush中向已经存在的Repository提交README.md改动. 命令例如以下: touch README.md git init git add README.md git commi ...

  7. 王立平--java se的简单项目创建以及具体解释

    创建项目的简单步骤: watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvdTAxMzQyNTUyNw==/font/5a6L5L2T/fontsize/400/ ...

  8. bzoj4078

    二分+2-sat 枚举第一个权值,二分第二个权值,然后2-sat检查,当第一个权值已经不能形成二分图时,再往下没意义,因为没法分成两个点集.(双指针好像跑得慢) #include<bits/st ...

  9. bzoj2115

    线性基+dfs树 我们先搞出dfs树,其实最终路径就是最初的路径和一些环异或. 环最多只有m-n+1,因为一共有m条边,然后有n-1条边在dfs树上,所以还剩m-n+1条边,都可以构成环. 所以dfs ...

  10. A. Jeff and Digits(cf)

    A. Jeff and Digits time limit per test 1 second memory limit per test 256 megabytes input standard i ...