OS + Linux Kernel IO PPC / TPC / select / poll / ppoll / epoll
Using epoll() For Asynchronous Network Programming
http://kovyrin.net/2006/04/13/epoll-asynchronous-network-programming/
2011-06-18 16:46 linux异步IO浅析
http://hi.baidu.com/_kouu/item/2b3cfecd49c17d10515058d9
Linux进程IO状况的实时监测
http://www.poluoluo.com/server/201011/98278.html
linux系统IO优化
http://nihongye.iteye.com/blog/246826
标准I/O开发
标准I/O操作都是基于流缓冲的，是符合ANSI C的标准I/O处理。
标准I/O提供流缓冲的目的是尽可能减少使用read和write调用的数量。
标准I/O提供了3种类型的缓冲存储：全缓冲，行缓冲和不带缓冲。
linux 下不带缓存的文件I/O主要用到5给函数：open、read、write、lseek和close
lseek 函数用于在制定的文件描述符中将文件指针定位到相应的位置
select 函数是用于处理I/O 复用的。
在I/O多路转接模型中，如果请求的I/O操作阻塞，他不是真正的阻塞I/O，
而是让其中的一个函数等待，在这期间，I/O还能进行其他操作。
iostat来对linux硬盘IO性能进行了解
Feb 3rd, 2009 Leave a comment | Trackback 转载本站文章请注明，转载自：扶凯[http://www.php-oa.com]
本文链接: http://www.php-oa.com/2009/02/03/iostat.html
以前一直不太会用这个参数。现在认真研究了一下iostat，因为刚好有台重要的服务器压力高,所以放上来分析一下.下面这台就是IO有压力过大的服务器
$iostat -x 1
Linux 2.6.33-fukai (fukai-laptop) _i686_ (2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
5.47 0.50 8.96 48.26 0.00 36.82
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 6.00 273.00 99.00 7.00 2240.00 2240.00 42.26 1.12 10.57 7.96 84.40
sdb 0.00 4.00 0.00 350.00 0.00 2068.00 5.91 0.55 1.58 0.54 18.80
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压力高)
另外 await 的参数也要多和 svctm 来参考。差的过高就一定有 IO 的问题。
avgqu-sz 也是个做 IO 调优时需要注意的地方，这个就是直接每次操作的数据的大小，
如果次数多，但数据拿的小的话，其实 IO 也会很小.如果数据拿的大，才IO 的数据会高。
也可以通过 avgqu-sz × ( r/s or w/s ) = rsec/s or wsec/s.也就是讲，读定速度是这个来决定的。
另外还可以参考
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
上面的 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。
定位IOWait高的一些方法和工具：
http://blog.csdn.net/guoguo1980/article/details/2333817
在Linux性能分析时经常使用的工具包括：top, iostat, vmstat等
IOWait高的一些处理方法
1、检查RAID的状态，比如是否正在重建或者没有初始化
2、替换操作系统的内核，最好使用发行版标准的Linux kernel，因为有比较多的补丁
3、检查/proc/sys/vm下面是否可以优化
4、是否使用了文件系统，文件系统是否有优化的选项，比如在RAID5上采用xfs文件系统时，
可以调节一些参数优化性能
5、客户端程序是否产生了过大的压力，比如磁盘的读写性能只有10MB/s，每个线程的读写
速度为5MB/s，那么如果读写线程数为20的话，无疑会造成IOWait过高
6、查看进程状态
ps -eo pid,user,wchan=WIDE-WCHAN-COLUMN -o s,cmd|awk ' $4 ~ /D/ {print $0}'
lsof -p $pid
7、使用block_dump
/etc/init.d/syslog stop
echo 1 > /proc/sys/vm/block_dump
sleep 60
dmesg | awk '/(READ|WRITE|dirtied)/ {process[$1]++} END {for (x in process) /
print process[x],x}' |sort -nr |awk '{print $2 " " $1}' | /
head -n 10
echo 0 > /proc/sys/vm/block_dump
/etc/init.d/syslog start
linux系统IO优化
http://nihongye.iteye.com/blog/246826
1.启用写回机制，优化随机写：
ext3支持三种模式:
journal_data,journal_data_ordered,journal_data_writeback
这三种模式在大多数情况下，性能从低到高，安全性从高到低，journal_data_writeback启用写回缓存，在遇到断电的情况会出现 数据不一致问题（如，硬盘本身带有写回缓存，默认也是启用的，断电同样的有问题;磁盘阵列控制卡也带有比较多的缓存），写回缓存的主要作用是能对随机读 写，起到优化作用。
ubuntu下：可以通过 sudo tune2fs -o journal_data_writeback /dev/hdx..来启用写回机制
注意：不要在/etc/fstab直接增加data=writeback的mount参数,会出现EXT3fs cannot change data mode on remount的错误
2.noatime
在读取，写文件时，文件系统会写入文件的访问时间，通过指定noatime,可以省略写入读取文件的访问时间(注意，可能影响一下软件的正常运行)，在/etc/fstab可以指定noatime,如下:
/dev/hda5 /media/hda5 ext3 defaults,noatime 0 2
其它优化手段，如果内存很大，可以控制swappness参数到20，减少应用的内存被交换到交换分区中，默认是60，因情况太复杂，这个参数的调整很难有普适的效果。
使用内存来优化：tmpfs具备先使用内存->然后使用swap的特性,/dev/shm就是这种类型，可以适当利用，重启后数据丢失。
基本检测手段
检测硬盘的读效率:hdparm -tT /dev/hda。
检测硬盘的写效率：time dd if=/dev/zero of=/media/hda5/tmp/my-file bs=4k count=65536
写入字符到/media/hda5/tmp/my-file文件，bs为块大小，count为快数
系统IO情况：vmstat,如果wa大说明瓶颈在io上。iostat用于监视io情况
end
