定位IO瓶颈的方法,iowait低,IO就没有到瓶颈?
通过分析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负载过高的问题呢?具体问题具体分析:
- 如果你的服务器用来做日志分析,要避免多个crontab交叠执行导致多进程随机IO(参考:随机IO vs 顺序IO),避免定期的压缩、解压大日志(这种任务会造成某段时间的IO抖动)。
- 如果是前端应用服务器,要避免程序频繁打本地日志、或者异常日志等。
- 如果是存储服务(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就没有到瓶颈?的更多相关文章
- linux系统瓶颈分析(精) CPU Memory IO Network
linux系统瓶颈分析(精) linux系统瓶颈分析(精) (2013-09-17 14:22:00) 分类: linux服务器瓶颈分析 1.0 性能监控介绍性能优化就是找到系统处理中的瓶颈以及去 ...
- linux下测试磁盘的读写IO速度-简易方法
linux下测试磁盘的读写IO速度-简易方法 参考资料:https://blog.csdn.net/zqtsx/article/details/25487185 一:使用hdparm命令 这是一个是用 ...
- Java.io下的方法是对磁盘上的文件进行磁盘操作
File类(java.io.*)可表示一个文件,也有可能是一个目录(在JAVA中文件和目录都属于这个类中,而且区分不是非常的明显). Java.io下的方法是对磁盘上的文件进行磁盘操作,但是无法读取文 ...
- Java.io.ObjectOutputStream.writeObject()方法实例
java.io.ObjectOutputStream.writeObject(Object obj) 方法将指定对象写入ObjectOutputStream.该对象的类,类的签名,以及类及其所有超类型 ...
- python开发IO模型:阻塞&非阻塞&异步IO&多路复用&selectors
一 IO模型介绍 为了更好地了解IO模型,我们需要事先回顾下:同步.异步.阻塞.非阻塞 同步(synchronous) IO和异步(asynchronous) IO,阻塞(blocking) IO和非 ...
- Android日志打印类LogUtils,能够定位到类名,方法名以及出现错误的行数并保存日志文件
Android日志打印类LogUtils,能够定位到类名,方法名以及出现错误的行数并保存日志文件 在开发中,我们常常用打印log的方式来调试我们的应用.在Java中我们常常使用方法System.out ...
- 文件IO 相关的包:java.io文件——API
文件IO 相关的包:java.io文件——API 1.Java.io.File类的使用(1)两种路径绝对路径:相对于当前路径:当前为 “工程名”(2)File类创建,对象为一个文件/目录,可能存在或不 ...
- linux基础编程:IO模型:阻塞/非阻塞/IO复用 同步/异步 Select/Epoll/AIO(转载)
IO概念 Linux的内核将所有外部设备都可以看做一个文件来操作.那么我们对与外部设备的操作都可以看做对文件进行操作.我们对一个文件的读写,都通过调用内核提供的系统调用:内核给我们返回一个file ...
- Scalable IO in Java【java高效IO】
第一次翻译,如有错误,请指正 1.Outline 大纲Scalable network services 高效网络服务 Event-driven processing 事件驱动处理 Reactor ...
- python IO模式(多路复用和异步IO深入理解)
1.事件渠道模型.事件渠道为异步IO的原型. 2.IO模式,一次IO调用会经历两个阶段.一.等待数据阶段,将数据从网络或者是磁盘读取到系统内核(kennel) 二.将数据从内核拷贝到进程中. 基于这两 ...
随机推荐
- 猫猫学iOS之UILabel设置圆角不成功所做调控更改
原创文章.欢迎转载.转载请注明:翟乃玉的博客 地址:http://blog.csdn.net/u013357243 如图问题 如图是我要做的效果 然而当我写好代码后,设置号label的layer圆角后 ...
- 用户向导左右滑动页面实现之ViewPager
接着上一篇博客.上一篇博客是用ImageSwitcher实现用户向导功能,如今用ViewPager实现同样的功能. 直接看代码: 布局文件activity_main.xml <RelativeL ...
- 初探Java中的异常处理
Java中的异常有以下几种: 1) Error:Java运行时的内部错误. 2) Exception:程序中应该捕获的异常. RuntimeException:因为编程产生的错误 ...
- android graphic(15)—fence
为何须要fence fence怎样使用 软件实现的opengl 硬件实现的opengl 上层使用canvas画图 上层使用opengl画图 下层合成 updateTexImage doComposeS ...
- HDU3183 RMQ/贪心
A Magic Lamp Problem Description Kiki likes traveling. One day she finds a magic lamp, unfortunately ...
- [NOIP 2014] 寻找道路
[题目链接] http://uoj.ac/problem/19 [算法] 首先,在反向图上从终点广搜,求出每个点是否可以在答案路径中 然后在正向图中求出源点至终点的最短路,同样可以使用广搜 时间复杂度 ...
- 【POJ 3764】 The xor-longest path
[题目链接] http://poj.org/problem?id=3764 [算法] 首先,我们用Si表示从节点i到根的路径边权异或和 那么,根据异或的性质,我们知道节点u和节点v路径上的边权异或和就 ...
- 莫队&&分块
今天兔哥讲了一波莫队,比较有趣,先加一个链接,这是她的教程 rabbithu.cnblogs.com 这里就不详细说了,其实就是两个指针来优化的暴力.一开始排序函数有问题,没用上莫队的核心思想:把查询 ...
- selenium3 + python - expected_conditions判断元素
expected_conditions 类 title_is: 判断当前页面的title是否完全等于(==)预期字符串,返回布尔值 title_contains : 判断当前页面的title是否包含预 ...
- input点击修改样式
<input id="geren" type="button" value="个人奖励" style="BORDER-TOP ...