定位IO瓶颈的一些方法
- - Linux - 操作系统 - ITeye博客IO瓶颈往往是我们可能会忽略的地方（我们常会看top、free、netstat等等，但经常会忽略IO的负载情况），今天给大家详细分享一下如何确认一台服务器的IO负载是否到达了瓶颈，以及可能优化、定位的点. 先来看一台典型的IO密集型服务器的cpu统计图：. 可以看到，CPU总使用率不高，平均1.3%，max到5.6%，虽然大部分都耗在了iowait上，但才百分之五左右，应该还没到瓶颈吧.
定位IO瓶颈的一些方法
标签：
io
瓶颈
方法
| 发表时间：2014-03-18 18:37 | 作者：blueswind8306
出处：http://www.iteye.com
IO瓶颈往往是我们可能会忽略的地方（我们常会看top、free、netstat等等，但经常会忽略IO的负载情况），今天给大家详细分享一下如何确认一台服务器的IO负载是否到达了瓶颈，以及可能优化、定位的点。
先来看一台典型的IO密集型服务器的cpu统计图：
可以看到，CPU总使用率不高，平均1.3%，max到5.6%，虽然大部分都耗在了iowait上，但才百分之五左右，应该还没到瓶颈吧？？？
错了！这里要特别注意： iowait≠IO负载，要看真实的IO负载情况，一般使用iostat –x 命令：
$ 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指的是“平均每次设备I/O操作的服务时间 (毫秒)”，而util指的是“一秒中I/O 操作的利用率，或者说一秒中有多少时间 I/O 队列是非空的。”
我们这里发现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的经典方式。
参考资料：
http://oplinux.com/order/iostat.html
http://bencane.com/2012/08/06/troubleshooting-high-io-wait-in-linux/
已有 0 人发表留言，猛击->> 这里<<-参与讨论
ITeye推荐
先来看一台典型的IO密集型服务器的cpu统计图：
可以看到，CPU总使用率不高，平均1.3%，max到5.6%，虽然大部分都耗在了iowait上，但才百分之五左右，应该还没到瓶颈吧？？？
错了！这里要特别注意： iowait≠IO负载，要看真实的IO负载情况，一般使用iostat –x 命令：
$ 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指的是“平均每次设备I/O操作的服务时间 (毫秒)”，而util指的是“一秒中I/O 操作的利用率，或者说一秒中有多少时间 I/O 队列是非空的。”
我们这里发现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的经典方式。
参考资料：
http://oplinux.com/order/iostat.html
http://bencane.com/2012/08/06/troubleshooting-high-io-wait-in-linux/
已有 0 人发表留言，猛击->> 这里<<-参与讨论
ITeye推荐
相关 [io 瓶颈 方法] 推荐：
可伸缩Web架构的4个问题：瓶颈，CPU，数据库，IO
- - 互联网 - ITeye博客在这篇文章中我将谈到关于大规模网站架构扩展和性能方面的一些问题. 首先让我们先来了解一些术语. 稍后我将对Web应用扩展过程中所遇到的不同问题进行讲解，例如：. Web系统的性能受多方面因素的影响，但大多数开发人员主要关心的是响应时间和可扩展性这两方面. 响应时间是指Web应用从收到请求到返回响应结果所花费的时间.
转：数据库如何抵抗随机IO：问题、方法与现实
- {ZuiZui} - 唐福林-博客雨随机IO几乎是令所有DBA谈虎色变的一个问题，这个问题，往往在数据量小的时候不出现，在数据量超过内存大小时，才陡然出现，令没有经验的DBA促不及防，也令有经验的DBA寝食难安. 传统的数据库架构对随机IO几乎没有还手之力. 传统数据库的核心通常是页级缓存、B+树、堆或索引组织表，这些机制，对随机IO的抵抗能力，都无一例外的可悲的差.
数据库如何抵抗随机IO：问题、方法与现实
- crystal - 风轻扬随机IO几乎是令所有DBA谈虎色变的一个问题，这个问题，往往在数据量小的时候不出现，在数据量超过内存大小时，才陡然出现，令没有经验的DBA促不及防，也令有经验的DBA寝食难安. 传统的数据库架构对随机IO几乎没有还手之力. 传统数据库的核心通常是页级缓存、B+树、堆或索引组织表，这些机制，对随机IO的抵抗能力，都无一例外的可悲的差.
物理IO与逻辑IO
- - 操作系统 - ITeye博客IO性能对于一个系统的影响是至关重要的. 一个系统经过多项优化以后，瓶颈往往落在数据库；而数据库经过多种优化以后，瓶颈最终会落到IO. 而IO性能的发展，明显落后于CPU的发展. Memchached也好，NoSql也好，这些流行技术的背后都在直接或者间接地回避IO瓶颈，从而提高系统性能. 上图层次比较多，但总的就是三部分.
linux异步IO浅析
- Sepher - kouu's home知道异步IO已经很久了，但是直到最近，才真正用它来解决一下实际问题（在一个CPU密集型的应用中，有一些需要处理的数据可能放在磁盘上. 预先知道这些数据的位置，所以预先发起异步IO读请求. 等到真正需要用到这些数据的时候，再等待异步IO完成. 使用了异步IO，在发起IO请求到实际使用数据这段时间内，程序还可以继续做其他事情）.
java nio和io的比较
- - 互联网 - ITeye博客第一部分：简单介绍NIO. 服务器在合理时间内处理大量客户机的请求的能力取决于服务器使用I/O流的效率，同时为成百上千的客户提供服务的服务器必须能并发的使用I/O服务. 用Java语言写的服务器，由于其线程与客户机之比几乎是一比一，因而易受到大量线程开销的影响，其结果是即导致性能问题，又缺乏伸缩性.
C++之文件IO操作流
- Nanqi - 博客园-首页原创精华区 前两节介绍了C++的IO流类库，标准设备IO操作流中部分预定义流对象的成员函数以及IO格式控制. 那今天我将继续介绍关于C++中的流操作内容——文件IO操作流fstream. 并会着重讲解C++是如何对文件进行操作的. 文件指存放在外部介质上的数据的集合. 大家都知道操作系统是以文件为单位来对数据进行管理的.
异步IO一定更好吗？
- Wolf - CNode社区在长林的文章《nodejs异步IO的实现》中提到，NodeJS通过libeio来实现IO操作的异步化，而libeio采用多线程的方式来模拟异步操作. 这里我需要强调一个观点，异步IO虽然是NodeJS一个非常重要的特点，但异步IO并不总是最好的，其他语言也一样. 在我的磁盘上有2个文件，我希望在一个程序里读取这2个文件，每次输出一个字符.
linux AIO （异步IO） 那点事儿
- zffl - CNode社区这时候进程至少会阻塞10次，而这可能会导致其他的上千个用户请求得不到处理，这当然是不能接受的.. Linux AIO 早就被提上议程，目前比较知名的有 Glibc 的 AIO 与 Kernel Native AIO. 我们用Glibc 的AIO 做个小实验，写一个简单的程序：异步方式读取一个文件，并注册异步回调函数：.