Apache 压力测试
[ 2009/08/23 12:45 | by selboo ]
压力测试是一种基本的质量保证行为，它是每个重要软件测试工作的一部分。压力测试的基本思路很简单：不是在常规条件下运行手动或自动测试，而是在计算机数量较少或系统资源匮乏的条件下运行测试。通常要进行压力测试的资源包括内部内存、CPU 可用性、磁盘空间和网络带宽等。一般用并发来做压力测试。
1.apache安装
下载：
从Apache官方网站http://httpd.apache.org/download.cgi下载httpd-2.0.58.tar.gz。
安装：
先解压缩tar文件
tar -zxvf httpd-2.0.58.tar.gz
(1)./configure -prefix=/usr/local/apache2test -enable-so -enable-shared=max -with-mpm=worker -enable-deflate -enable-headers -enable-rewrite -enable-proxy -enable-proxy -enable-ssl -with-ssl=/path/to/install/openssl_0.97i -enable-modules=all && make && make install
(这是正式服务器上的apache2的编译参数，其中–with-mpm=worker –with-ssl=/path/to/install/openssl_0.97i可以根据实际情况做出修改)
然后安装php，并且在/usr/local/apache2test/conf目录下的httpd.conf里面的DSO支持之后加入
AddType application/x-httpd-php .php .phtml .html .htm
AddType application/x-httpd-php-source .phps
最后将测试的php网页文件添加到/usr/local/apache2test/htdocs目录下
(2) make
(3)make install
2.测试工具说明以及安装
ab:
ab是Apache超文本传输协议(HTTP)的性能测试工具。 其设计意图是描绘当前所安装的Apache的执行性能，主要是显示你安装的Apache每秒可以处理多少个请求；
概要:运行/usr/local/apache-install-path/bin/ab -help查看ab的具体命令选项；
命令选项-c concurrency 一次产生的请求个数。默认是一次一个。
-n requests 在测试会话中所执行的请求个数。 默认时，仅执行一个请求，但通常其结果不 具有代表意义
运行结果:主要要注意的是以下内容
Time taken for tests: 总共执行所花费的时间.(以上 1000 次共多久)
Requests per second: 每秒平均可以处理多少个connection.
备注:每次仅仅能针对一个连接做重复的测试。
Siege:
是一个压力测试和评测工具，设计用于WEB开发这评估应用在压力下的承受能力：可以根据配置对一个WEB站点进行多用户的并发访问，记录每个用户所有请求过程的相应时间，并在一定数量的并发访问下重复进行。
下载/安装
Siege时一个开放源代码项目，可以在http://www.google.com上查找
备注：最好选择2.5以上版本，因为高版本多包括一个辅助工具，能够做增量压力测试，低版本不包括此工具。
安装：
./configure -prefix=/path/to/install && make && make install
使用说明:
siege使用
在/path/to/install/bin/目录下创建需要测试的链接文件，如www.test.com.url,添加需要的测试的链接
http://10.5.3.122/test/google.php/
http://10.5.3.122/test/baidu.php/
http://10.5.3.122/test/sogou.php/
然后保存。
siege使用样例：
siege -c 20 -r 2 -f www.chedong.com.url
参数说明：
-c 20 并发20个用户
-r 2 重复循环2次
-f www.test.com.url 任务列表：URL列表
输出样例：
** Siege 2.59
** Preparing 20 concurrent users for battle. 这次“战斗”准备了20个并发用户
The server is now under siege.. done. 服务在“围攻”测试中：
Transactions: 40 hits 完成40次处理
Availability: 100.00 % 成功率
Elapsed time: 7.67 secs 总共用时
Data transferred: 877340 bytes 共数据传输：877340字节
Response time: 1.65 secs 相应用时1.65秒：显示网络连接的速度
Transaction rate: 5.22 trans/sec 平均每秒完成5.22次处理：表示服务器后台处理的速度
Throughput: 114385.92 bytes/sec 平均每秒传送数据：114385.92字节
Concurrency: 8.59 最高并发数 8.59
Successful transactions: 40 成功处理次数
Failed transactions: 0 失败处理次数
bombardment使用样例:
bombardment www.test.com.url 5 3 4 1
初始化URL列表：www.test.com.url
初始化为：5个用户
每次增加：3个用户
运行：4次
每个客户端之间的延迟为：1秒
输出样例和siege一致，但是会在每一次增量结束之后都有输出。
3.测试方法说明
测试步骤：
方法1.安装apache2后，直接使用apache2的默认设置配置，不做任何修改，进行测试；
方法2.按照以前文档提出的Web容量规划和内存的大小，计算出相应的启动进程数，配置httpd.conf文件，再进行测试；
ServerLimit 400
StartServers 20
MinSpareServers 20
MaxSpareServers 50
MaxClients 300
MaxRequestsPerChild 10000
方法3.超过极限设置，进行测试。(规划容量的2倍进行)
1000个链接，分为不同的并发数请求，10、50、100、200、300、500
ab测试:
/usr/local/apache2.53/bin/ab -n 1000 -c 10 http://10.5.3.122/test/google.php/
/usr/local/apache2.53/bin/ab -n 1000 -c 50 http://10.5.3.122/test/google.php/
/usr/local/apache2.53/bin/ab -n 1000 -c 100 http://10.5.3.122/test/google.php/
/usr/local/apache2.53/bin/ab -n 1000 -c 200 http://10.5.3.122/test/google.php/
/usr/local/apache2.53/bin/ab -n 1000 -c 300 http://10.5.3.122/test/google.php/
/usr/local/apache2.53/bin/ab -n 1000 -c 500 http://10.5.3.122/test/google.php/
siege测试:
/usr/local/siege/bin/siege -c 10 -r 100 -f www.test.com.url
/usr/local/siege/bin/siege -c 50 -r 20 -f www.test.com.url
/usr/local/siege/bin/siege -c 100 -r 10 -f www.test.com.url
/usr/local/siege/bin/siege -c 200 -r 5 -f www.test.com.url
/usr/local/siege/bin/siege -c 300 -r 3 -f www.test.com.url
/usr/local/siege/bin/siege -c 500 -r 2 -f www.test.com.url
增量测试:
/usr/local/siege/bin/bombardment www.test.com.url 1 100 5 1
/usr/local/siege/bin/bombardment www.test.com.url 1 100 6 1
4.测试结果总结
ab测试:测试并发连接数在50~500的情况下，方法2比方法1性能略有提升，但是相差在10个并发连接数左右，并且方法1方法2在测试并发数100的情况下，实际并发数都相差无几。
siege测试:测试并发数从50之后直到500，性能都有提升，并且在测试并发数100、200、500的情况下，提升相差10~30个实际并发数。
bombardment测试:相差不大。本次测试的结果不太理想，性能的变化不显著，也不明显，可以所属于失败的测试结果。
分析原因：
1.本身硬件配置不高，所以默认设置和修改后的设置变化不明显，对性能的提升也明显不足；
2.负载情况太少，由于系统性能原因，增量测试都不能过大的进行，系统性能load average过高；
3.测试页面程序也太少，没有太大说服力。
网站性能测试报告模板
下载文件 (已下载 255 次)
1.apache安装
下载：
从Apache官方网站http://httpd.apache.org/download.cgi下载httpd-2.0.58.tar.gz。
安装：
先解压缩tar文件
tar -zxvf httpd-2.0.58.tar.gz
(1)./configure -prefix=/usr/local/apache2test -enable-so -enable-shared=max -with-mpm=worker -enable-deflate -enable-headers -enable-rewrite -enable-proxy -enable-proxy -enable-ssl -with-ssl=/path/to/install/openssl_0.97i -enable-modules=all && make && make install
(这是正式服务器上的apache2的编译参数，其中–with-mpm=worker –with-ssl=/path/to/install/openssl_0.97i可以根据实际情况做出修改)
然后安装php，并且在/usr/local/apache2test/conf目录下的httpd.conf里面的DSO支持之后加入
AddType application/x-httpd-php .php .phtml .html .htm
AddType application/x-httpd-php-source .phps
最后将测试的php网页文件添加到/usr/local/apache2test/htdocs目录下
(2) make
(3)make install
2.测试工具说明以及安装
ab:
ab是Apache超文本传输协议(HTTP)的性能测试工具。 其设计意图是描绘当前所安装的Apache的执行性能，主要是显示你安装的Apache每秒可以处理多少个请求；
概要:运行/usr/local/apache-install-path/bin/ab -help查看ab的具体命令选项；
命令选项-c concurrency 一次产生的请求个数。默认是一次一个。
-n requests 在测试会话中所执行的请求个数。 默认时，仅执行一个请求，但通常其结果不 具有代表意义
运行结果:主要要注意的是以下内容
Time taken for tests: 总共执行所花费的时间.(以上 1000 次共多久)
Requests per second: 每秒平均可以处理多少个connection.
备注:每次仅仅能针对一个连接做重复的测试。
Siege:
是一个压力测试和评测工具，设计用于WEB开发这评估应用在压力下的承受能力：可以根据配置对一个WEB站点进行多用户的并发访问，记录每个用户所有请求过程的相应时间，并在一定数量的并发访问下重复进行。
下载/安装
Siege时一个开放源代码项目，可以在http://www.google.com上查找
备注：最好选择2.5以上版本，因为高版本多包括一个辅助工具，能够做增量压力测试，低版本不包括此工具。
安装：
./configure -prefix=/path/to/install && make && make install
使用说明:
siege使用
在/path/to/install/bin/目录下创建需要测试的链接文件，如www.test.com.url,添加需要的测试的链接
http://10.5.3.122/test/google.php/
http://10.5.3.122/test/baidu.php/
http://10.5.3.122/test/sogou.php/
然后保存。
siege使用样例：
siege -c 20 -r 2 -f www.chedong.com.url
参数说明：
-c 20 并发20个用户
-r 2 重复循环2次
-f www.test.com.url 任务列表：URL列表
输出样例：
** Siege 2.59
** Preparing 20 concurrent users for battle. 这次“战斗”准备了20个并发用户
The server is now under siege.. done. 服务在“围攻”测试中：
Transactions: 40 hits 完成40次处理
Availability: 100.00 % 成功率
Elapsed time: 7.67 secs 总共用时
Data transferred: 877340 bytes 共数据传输：877340字节
Response time: 1.65 secs 相应用时1.65秒：显示网络连接的速度
Transaction rate: 5.22 trans/sec 平均每秒完成5.22次处理：表示服务器后台处理的速度
Throughput: 114385.92 bytes/sec 平均每秒传送数据：114385.92字节
Concurrency: 8.59 最高并发数 8.59
Successful transactions: 40 成功处理次数
Failed transactions: 0 失败处理次数
bombardment使用样例:
bombardment www.test.com.url 5 3 4 1
初始化URL列表：www.test.com.url
初始化为：5个用户
每次增加：3个用户
运行：4次
每个客户端之间的延迟为：1秒
输出样例和siege一致，但是会在每一次增量结束之后都有输出。
3.测试方法说明
测试步骤：
方法1.安装apache2后，直接使用apache2的默认设置配置，不做任何修改，进行测试；
方法2.按照以前文档提出的Web容量规划和内存的大小，计算出相应的启动进程数，配置httpd.conf文件，再进行测试；
ServerLimit 400
StartServers 20
MinSpareServers 20
MaxSpareServers 50
MaxClients 300
MaxRequestsPerChild 10000
方法3.超过极限设置，进行测试。(规划容量的2倍进行)
1000个链接，分为不同的并发数请求，10、50、100、200、300、500
ab测试:
/usr/local/apache2.53/bin/ab -n 1000 -c 10 http://10.5.3.122/test/google.php/
/usr/local/apache2.53/bin/ab -n 1000 -c 50 http://10.5.3.122/test/google.php/
/usr/local/apache2.53/bin/ab -n 1000 -c 100 http://10.5.3.122/test/google.php/
/usr/local/apache2.53/bin/ab -n 1000 -c 200 http://10.5.3.122/test/google.php/
/usr/local/apache2.53/bin/ab -n 1000 -c 300 http://10.5.3.122/test/google.php/
/usr/local/apache2.53/bin/ab -n 1000 -c 500 http://10.5.3.122/test/google.php/
siege测试:
/usr/local/siege/bin/siege -c 10 -r 100 -f www.test.com.url
/usr/local/siege/bin/siege -c 50 -r 20 -f www.test.com.url
/usr/local/siege/bin/siege -c 100 -r 10 -f www.test.com.url
/usr/local/siege/bin/siege -c 200 -r 5 -f www.test.com.url
/usr/local/siege/bin/siege -c 300 -r 3 -f www.test.com.url
/usr/local/siege/bin/siege -c 500 -r 2 -f www.test.com.url
增量测试:
/usr/local/siege/bin/bombardment www.test.com.url 1 100 5 1
/usr/local/siege/bin/bombardment www.test.com.url 1 100 6 1
4.测试结果总结
ab测试:测试并发连接数在50~500的情况下，方法2比方法1性能略有提升，但是相差在10个并发连接数左右，并且方法1方法2在测试并发数100的情况下，实际并发数都相差无几。
siege测试:测试并发数从50之后直到500，性能都有提升，并且在测试并发数100、200、500的情况下，提升相差10~30个实际并发数。
bombardment测试:相差不大。本次测试的结果不太理想，性能的变化不显著，也不明显，可以所属于失败的测试结果。
分析原因：
1.本身硬件配置不高，所以默认设置和修改后的设置变化不明显，对性能的提升也明显不足；
2.负载情况太少，由于系统性能原因，增量测试都不能过大的进行，系统性能load average过高；
3.测试页面程序也太少，没有太大说服力。
网站性能测试报告模板
下载文件 (已下载 255 次)mysql压力测试工具：mysqlslap
[ 2009/04/09 00:13 | by selboo ]
mysqlslap是一个mysql官方提供的压力测试工具。以下是比较重要的参数：
–defaults-file，配置文件存放位置
–concurrency，并发数
–engines，引擎
–iterations，迭代的实验次数
–socket，socket文件位置
自动测试：
–auto-generate-sql，自动产生测试SQL
–auto-generate-sql-load-type，测试SQL的类型。类型有mixed，update，write，key，read。
–number-of-queries，执行的SQL总数量
–number-int-cols，表内int列的数量
–number-char-cols，表内char列的数量
例如：
shell>mysqlslap –defaults-file=/u01/mysql1/mysql/my.cnf –concurrency=50,100 –iterations=1 –number-int-cols=4 –auto-generate-sql –auto-generate-sql-load-type=write –engine=myisam –number-of-queries=200 -S/tmp/mysql1.sock
Benchmark
Running for engine myisam
Average number of seconds to run all queries: 0.016 seconds
Minimum number of seconds to run all queries: 0.016 seconds
Maximum number of seconds to run all queries: 0.016 seconds
Number of clients running queries: 50
Average number of queries per client: 4
Benchmark
Running for engine myisam
Average number of seconds to run all queries: 0.265 seconds
Minimum number of seconds to run all queries: 0.265 seconds
Maximum number of seconds to run all queries: 0.265 seconds
Number of clients running queries: 100
Average number of queries per client: 2
指定数据库的测试：
–create-schema，指定数据库名称
–query，指定SQL语句，可以定位到某个包含SQL的文件
例如：
shell>mysqlslap –defaults-file=/u01/mysql1/mysql/my.cnf –concurrency=25,50 –iterations=1 –create-schema=test –query=/u01/test.sql -S/tmp/mysql1.sock
Benchmark
Average number of seconds to run all queries: 0.018 seconds
Minimum number of seconds to run all queries: 0.018 seconds
Maximum number of seconds to run all queries: 0.018 seconds
Number of clients running queries: 25
Average number of queries per client: 1
Benchmark
Average number of seconds to run all queries: 0.011 seconds
Minimum number of seconds to run all queries: 0.011 seconds
Maximum number of seconds to run all queries: 0.011 seconds
Number of clients running queries: 50
Average number of queries per client: 1
–defaults-file，配置文件存放位置
–concurrency，并发数
–engines，引擎
–iterations，迭代的实验次数
–socket，socket文件位置
自动测试：
–auto-generate-sql，自动产生测试SQL
–auto-generate-sql-load-type，测试SQL的类型。类型有mixed，update，write，key，read。
–number-of-queries，执行的SQL总数量
–number-int-cols，表内int列的数量
–number-char-cols，表内char列的数量
例如：
shell>mysqlslap –defaults-file=/u01/mysql1/mysql/my.cnf –concurrency=50,100 –iterations=1 –number-int-cols=4 –auto-generate-sql –auto-generate-sql-load-type=write –engine=myisam –number-of-queries=200 -S/tmp/mysql1.sock
Benchmark
Running for engine myisam
Average number of seconds to run all queries: 0.016 seconds
Minimum number of seconds to run all queries: 0.016 seconds
Maximum number of seconds to run all queries: 0.016 seconds
Number of clients running queries: 50
Average number of queries per client: 4
Benchmark
Running for engine myisam
Average number of seconds to run all queries: 0.265 seconds
Minimum number of seconds to run all queries: 0.265 seconds
Maximum number of seconds to run all queries: 0.265 seconds
Number of clients running queries: 100
Average number of queries per client: 2
指定数据库的测试：
–create-schema，指定数据库名称
–query，指定SQL语句，可以定位到某个包含SQL的文件
例如：
shell>mysqlslap –defaults-file=/u01/mysql1/mysql/my.cnf –concurrency=25,50 –iterations=1 –create-schema=test –query=/u01/test.sql -S/tmp/mysql1.sock
Benchmark
Average number of seconds to run all queries: 0.018 seconds
Minimum number of seconds to run all queries: 0.018 seconds
Maximum number of seconds to run all queries: 0.018 seconds
Number of clients running queries: 25
Average number of queries per client: 1
Benchmark
Average number of seconds to run all queries: 0.011 seconds
Minimum number of seconds to run all queries: 0.011 seconds
Maximum number of seconds to run all queries: 0.011 seconds
Number of clients running queries: 50
Average number of queries per client: 1
ext3,ext4,xfs的性能测试对比
[ 2009/03/11 22:00 | by selboo ]
from:http://www.php-oa.com/2009/03/10/ext3ext4xfs.html
上周用iozone对ext3,ext4,xfs做了一次全面的测试，不同的块大小,不同的文件大小,读写,重读,写,重写,大块重写之类的性能进行了全面的测试.
ext4的稳定版本是2.6.28,所以在这个测试时是用的2.6.28.文件的大小分别选择了1G,2G,4G的数据。
为了不影响测试，不让内存缓存数据，我用的1G内存.下面是4G时的表现
总结，哈哈，很奇怪吧。ext4全面战胜ext3.但xfs全面战胜ext*.呵呵。另外，ext4的格式化比ext3快多了，有提高.但xfs格式化6T,按下回车就完了.
上周用iozone对ext3,ext4,xfs做了一次全面的测试，不同的块大小,不同的文件大小,读写,重读,写,重写,大块重写之类的性能进行了全面的测试.
ext4的稳定版本是2.6.28,所以在这个测试时是用的2.6.28.文件的大小分别选择了1G,2G,4G的数据。
为了不影响测试，不让内存缓存数据，我用的1G内存.下面是4G时的表现
总结，哈哈，很奇怪吧。ext4全面战胜ext3.但xfs全面战胜ext*.呵呵。另外，ext4的格式化比ext3快多了，有提高.但xfs格式化6T,按下回车就完了.
iostat对linux硬盘IO性能测试
[ 2009/02/04 21:49 | by selboo ]
fom:http://www.php-oa.com/2009/02/03/iostat.html
以前一直不太会用这个参数。现在认真研究了一下iostat，因为刚好有台重要的服务器压力高,所以放上来分析一下.下面这台就是IO有压力过大的服务器
# iostat -x 1 10
Linux 2.6.18-92.el5xen 02/03/2009
avg-cpu: %user %nice %system %iowait %steal %idle
1.10 0.00 4.82 39.54 0.07 54.46
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 3.50 0.40 2.50 5.60 48.00 18.48 0.00 0.97 0.97 0.28
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdd 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sde 0.00 0.10 0.30 0.20 2.40 2.40 9.60 0.00 1.60 1.60 0.08
sdf 17.40 0.50 102.00 0.20 12095.20 5.60 118.40 0.70 6.81 2.09 21.36
sdg 232.40 1.90 379.70 0.50 76451.20 19.20 201.13 4.94 13.78 2.45 93.16
rrqm/s: 每秒进行 merge 的读操作数目。即 delta(rmerge)/s
wrqm/s: 每秒进行 merge 的写操作数目。即 delta(wmerge)/s
r/s: 每秒完成的读 I/O 设备次数。即 delta(rio)/s
w/s: 每秒完成的写 I/O 设备次数。即 delta(wio)/s
rsec/s: 每秒读扇区数。即 delta(rsect)/s
wsec/s: 每秒写扇区数。即 delta(wsect)/s
rkB/s: 每秒读K字节数。是 rsect/s 的一半，因为每扇区大小为512字节。(需要计算)
wkB/s: 每秒写K字节数。是 wsect/s 的一半。(需要计算)
avgrq-sz: 平均每次设备I/O操作的数据大小 (扇区)。delta(rsect+wsect)/delta(rio+wio)
avgqu-sz: 平均I/O队列长度。即 delta(aveq)/s/1000 (因为aveq的单位为毫秒)。
await: 平均每次设备I/O操作的等待时间 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)
svctm: 平均每次设备I/O操作的服务时间 (毫秒)。即 delta(use)/delta(rio+wio)
%util: 一秒中有百分之多少的时间用于 I/O 操作，或者说一秒中有多少时间 I/O 队列是非空的。即 delta(use)/s/1000 (因为use的单位为毫秒)
如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘
可能存在瓶颈。
idle小于70% IO压力就较大了,一般读取速度有较多的wait.
同时可以结合vmstat 查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比,高过30%时IO压力高)
另外还可以参考
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 洪水。
别人一个不错的例子.(I/O 系统 vs. 超市排队)
举一个例子，我们在超市排队 checkout 时，怎么决定该去哪个交款台呢? 首当是看排的队人数，5个人总比20人要快吧? 除了数人头，我们也常常看看前面人购买的东西多少，如果前面有个采购了一星期食品的大妈，那么可以考虑换个队排了。还有就是收银员的速度了，如果碰上了连 钱都点不清楚的新手，那就有的等了。另外，时机也很重要，可能 5 分钟前还人满为患的收款台，现在已是人去楼空，这时候交款可是很爽啊，当然，前提是那过去的 5 分钟里所做的事情比排队要有意义 (不过我还没发现什么事情比排队还无聊的)。
I/O 系统也和超市排队有很多类似之处:
r/s+w/s 类似于交款人的总数
平均队列长度(avgqu-sz)类似于单位时间里平均排队人的个数
平均服务时间(svctm)类似于收银员的收款速度
平均等待时间(await)类似于平均每人的等待时间
平均I/O数据(avgrq-sz)类似于平均每人所买的东西多少
I/O 操作率 (%util)类似于收款台前有人排队的时间比例。
我们可以根据这些数据分析出 I/O 请求的模式，以及 I/O 的速度和响应时间。
下面是别人写的这个参数输出的分析
# iostat -x 1
avg-cpu: %user %nice %sys %idle
16.24 0.00 4.31 79.44
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/cciss/c0d0
0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
/dev/cciss/c0d0p1
0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
/dev/cciss/c0d0p2
0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
上面的 iostat 输出表明秒有 28.57 次设备 I/O 操作: 总IO(io)/s = r/s(读) +w/s(写) = 1.02+27.55 = 28.57 (次/秒) 其中写操作占了主体 (w:r = 27:1)。
平均每次设备 I/O 操作只需要 5ms 就可以完成，但每个 I/O 请求却需要等上 78ms，为什么? 因为发出的 I/O 请求太多 (每秒钟约 29 个)，假设这些请求是同时发出的，那么平均等待时间可以这样计算:
平均等待时间 = 单个 I/O 服务时间 * ( 1 + 2 + ... + 请求总数-1) / 请求总数
应用到上面的例子: 平均等待时间 = 5ms * (1+2+...+28)/29 = 70ms，和 iostat 给出的78ms 的平均等待时间很接近。这反过来表明 I/O 是同时发起的。
每秒发出的 I/O 请求很多 (约 29 个)，平均队列却不长 (只有 2 个 左右)，这表明这 29 个请求的到来并不均匀，大部分时间 I/O 是空闲的。
一秒中有 14.29% 的时间 I/O 队列中是有请求的，也就是说，85.71% 的时间里 I/O 系统无事可做，所有 29 个 I/O 请求都在142毫秒之内处理掉了。
delta(ruse+wuse)/delta(io) = await = 78.21 => delta(ruse+wuse)/s =78.21 * delta(io)/s = 78.21*28.57 = 2232.8，表明每秒内的I/O请求总共需要等待2232.8ms。所以平均队列长度应为 2232.8ms/1000ms = 2.23，而 iostat 给出的平均队列长度 (avgqu-sz) 却为 22.35，为什么?! 因为 iostat 中有 bug，avgqu-sz 值应为 2.23，而不是 22.35。
以前一直不太会用这个参数。现在认真研究了一下iostat，因为刚好有台重要的服务器压力高,所以放上来分析一下.下面这台就是IO有压力过大的服务器
# iostat -x 1 10
Linux 2.6.18-92.el5xen 02/03/2009
avg-cpu: %user %nice %system %iowait %steal %idle
1.10 0.00 4.82 39.54 0.07 54.46
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 3.50 0.40 2.50 5.60 48.00 18.48 0.00 0.97 0.97 0.28
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdd 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sde 0.00 0.10 0.30 0.20 2.40 2.40 9.60 0.00 1.60 1.60 0.08
sdf 17.40 0.50 102.00 0.20 12095.20 5.60 118.40 0.70 6.81 2.09 21.36
sdg 232.40 1.90 379.70 0.50 76451.20 19.20 201.13 4.94 13.78 2.45 93.16
rrqm/s: 每秒进行 merge 的读操作数目。即 delta(rmerge)/s
wrqm/s: 每秒进行 merge 的写操作数目。即 delta(wmerge)/s
r/s: 每秒完成的读 I/O 设备次数。即 delta(rio)/s
w/s: 每秒完成的写 I/O 设备次数。即 delta(wio)/s
rsec/s: 每秒读扇区数。即 delta(rsect)/s
wsec/s: 每秒写扇区数。即 delta(wsect)/s
rkB/s: 每秒读K字节数。是 rsect/s 的一半，因为每扇区大小为512字节。(需要计算)
wkB/s: 每秒写K字节数。是 wsect/s 的一半。(需要计算)
avgrq-sz: 平均每次设备I/O操作的数据大小 (扇区)。delta(rsect+wsect)/delta(rio+wio)
avgqu-sz: 平均I/O队列长度。即 delta(aveq)/s/1000 (因为aveq的单位为毫秒)。
await: 平均每次设备I/O操作的等待时间 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)
svctm: 平均每次设备I/O操作的服务时间 (毫秒)。即 delta(use)/delta(rio+wio)
%util: 一秒中有百分之多少的时间用于 I/O 操作，或者说一秒中有多少时间 I/O 队列是非空的。即 delta(use)/s/1000 (因为use的单位为毫秒)
如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘
可能存在瓶颈。
idle小于70% IO压力就较大了,一般读取速度有较多的wait.
同时可以结合vmstat 查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比,高过30%时IO压力高)
另外还可以参考
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 洪水。
别人一个不错的例子.(I/O 系统 vs. 超市排队)
举一个例子，我们在超市排队 checkout 时，怎么决定该去哪个交款台呢? 首当是看排的队人数，5个人总比20人要快吧? 除了数人头，我们也常常看看前面人购买的东西多少，如果前面有个采购了一星期食品的大妈，那么可以考虑换个队排了。还有就是收银员的速度了，如果碰上了连 钱都点不清楚的新手，那就有的等了。另外，时机也很重要，可能 5 分钟前还人满为患的收款台，现在已是人去楼空，这时候交款可是很爽啊，当然，前提是那过去的 5 分钟里所做的事情比排队要有意义 (不过我还没发现什么事情比排队还无聊的)。
I/O 系统也和超市排队有很多类似之处:
r/s+w/s 类似于交款人的总数
平均队列长度(avgqu-sz)类似于单位时间里平均排队人的个数
平均服务时间(svctm)类似于收银员的收款速度
平均等待时间(await)类似于平均每人的等待时间
平均I/O数据(avgrq-sz)类似于平均每人所买的东西多少
I/O 操作率 (%util)类似于收款台前有人排队的时间比例。
我们可以根据这些数据分析出 I/O 请求的模式，以及 I/O 的速度和响应时间。
下面是别人写的这个参数输出的分析
# iostat -x 1
avg-cpu: %user %nice %sys %idle
16.24 0.00 4.31 79.44
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/cciss/c0d0
0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
/dev/cciss/c0d0p1
0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
/dev/cciss/c0d0p2
0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
上面的 iostat 输出表明秒有 28.57 次设备 I/O 操作: 总IO(io)/s = r/s(读) +w/s(写) = 1.02+27.55 = 28.57 (次/秒) 其中写操作占了主体 (w:r = 27:1)。
平均每次设备 I/O 操作只需要 5ms 就可以完成，但每个 I/O 请求却需要等上 78ms，为什么? 因为发出的 I/O 请求太多 (每秒钟约 29 个)，假设这些请求是同时发出的，那么平均等待时间可以这样计算:
平均等待时间 = 单个 I/O 服务时间 * ( 1 + 2 + ... + 请求总数-1) / 请求总数
应用到上面的例子: 平均等待时间 = 5ms * (1+2+...+28)/29 = 70ms，和 iostat 给出的78ms 的平均等待时间很接近。这反过来表明 I/O 是同时发起的。
每秒发出的 I/O 请求很多 (约 29 个)，平均队列却不长 (只有 2 个 左右)，这表明这 29 个请求的到来并不均匀，大部分时间 I/O 是空闲的。
一秒中有 14.29% 的时间 I/O 队列中是有请求的，也就是说，85.71% 的时间里 I/O 系统无事可做，所有 29 个 I/O 请求都在142毫秒之内处理掉了。
delta(ruse+wuse)/delta(io) = await = 78.21 => delta(ruse+wuse)/s =78.21 * delta(io)/s = 78.21*28.57 = 2232.8，表明每秒内的I/O请求总共需要等待2232.8ms。所以平均队列长度应为 2232.8ms/1000ms = 2.23，而 iostat 给出的平均队列长度 (avgqu-sz) 却为 22.35，为什么?! 因为 iostat 中有 bug，avgqu-sz 值应为 2.23，而不是 22.35。
