分类： LINUX
2008-05-21 12:01:42
IO系统是整个系统中最慢的部分，因为它需要真正的物理操作磁盘的转动和检索。比起内存来要差几个数量级。Linux内核将硬盘IO分页，每一页的大小默认为4K。这时，内存和磁盘的读写以页为单位进行，这些页叫做内存页。用time命令可以检查页的大小：
# /usr/bin/time -v date
Page size (bytes): 4096
主要页错误（Major Page Faults）和次要页错误（Minor Page Faults）：
MPF（Major Page Faults）表示进程需要的数据并不在内存中，需要从磁盘读取。
一旦内存页读入到内存的缓冲区中，程序就在内存中读取或写入数据，叫做MnPF（Minor Page Faults）。MnPF通过重复使用内存页而缩短了内核时间。Time命令可以显示一个进程中MPF和MnPF的数量，在evolution程序第一次启动的时候会有很多MPF：
# /usr/bin/time -v evolution
Major (requiring I/O) page faults: 163
Minor (reclaiming a frame) page faults: 5918
如果再次启动evolution程序，我们就看到MPF消失了，因为此时进程需要的数据已经全部在内存中了：
# /usr/bin/time -v evolution
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 5581
当进程不断的进行IO操作的时候，系统会将这些数据缓存到内存中。所以我们会看到系统的FreeMemory越来越少，而Cache越来越大。如下:
# cat /proc/meminfo
MemTotal: 2075672 kB
MemFree: 52528 kB
Buffers: 24596 kB
Cached: 1766844 kB
有些人为系统的可用内存太少而担心，而事实不是这样，这种情况恰恰证明系统正在高效的利用cache，进而减少MPF，增加MnPF。但从这个输出我们无法断定内存是否为系统瓶颈。
前面讲了内存页的定义，接下来我们说说内存页的分类：
1. Read Pages-这些页通过MPF从磁盘读入，并且是只读的。这些页存在与cache中包括不能修改的静态文件，二进制文件，库文件。内核在需要的时候会将他们读入内存，当内存资源紧张时，内核会释一些放此类的内存页，当程序在此需要的时候，就只能通过MPF重新读入。
2. Dirty Pages-这些页是内核在内存中修改过的页面。这些页面需要同步回磁盘上。Pdflush负责将他们写回磁盘。当内存不够时，kswapd就会触发pdflush将页面写回磁盘以释放内存。
3. Anonymous Pages-这些页属于某个进程，但是没有任何磁盘文件与之相关。他们不能和磁盘同步。当内存不够时，kswapd会将他们写入swap分区。
应用程序可以用系统调用fsync()和sync()将Dirty Page立即写回磁盘。如果应用程序没有调用此类函数，pdflush进程会定期与磁盘进行同步。
接下来我们分析一些具体的情况，在这些情况下I/O会成为系统的瓶颈。我们会用到工具top，vmstat，iostat，sar等。每一个工具的输出都从不同的方面反映除系统的性能情况。
情况1：同一时间进行大量的I/O操作
在这种情况时我们会发现CPU的wa时间百分比会上升，证明系统的idle时间大部分都是在等待I/O操作。
# vmstat 1
procs -----memory----- ---swap---io---- --system--cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
3 2 0 55452 9236 1739020 0 0 9352 0 2580 8771 20 24 0 57
2 3 0 53888 9232 1740836 0 0 14860 0 2642 8954 23 25 0 52
2 2 0 51856 9212 1742928 0 0 12688 0 2636 8487 23 25 0 52
从这个输出我们可以看到CPU有50%的时间都在等待I/O操作，我们还可以看到系统的bi值很大，证明系统有大量的I/O请求将磁盘内容读入内存。
没有很好的工具能看到到底是哪个进程在进行I/O读写。但我们可以通过top命令的输出来猜测
# top -d 1
top - 19:45:07 up 1:40, 3 users, load average: 6.36, 5.87, 4.40
Tasks: 119 total, 3 running, 116 sleeping, 0 stopped, 0 zombie
Cpu(s): 5.9% us, 87.1% sy, 0.0% ni, 0.0% id, 5.9% wa, 1.0% hi, 0.0% si
Mem: 2075672k total, 2022668k used, 53004k free, 7156k buffers
Swap: 2031608k total, 132k used, 2031476k free, 1709372k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ nFLT COMMAND
3069 root 5 -10 450m 303m 280m S 61.5 15.0 10:56.68 4562 vmware-vmx
3016 root 5 -10 447m 300m 280m S 21.8 14.8 12:22.83 3978 vmware-vmx
3494 root 5 -10 402m 255m 251m S 3.0 12.6 1:08.65 3829 vmware-vmx
3624 root 5 -10 401m 256m 251m S 1.0 12.6 0:29.92 3747 vmware-vmx
将top的输出通过faults进行排序。我们可以看到vmware产生最多的page faults。也就是说它进行了大量的IO操作。
情况2：管道太小
任何I/O操作都需要一定的时间，而且这些时间对于硬盘来说是确定的，它包含磁盘旋转的延时RD（rotation delay）和磁头搜索时间DS（disk seek）。RD由磁盘转速（RPM）决定。RD是磁盘旋转一周所需时间的一半。如RPM为10000.
RPS=RPM/60=166
1/166=0.0006=6ms 磁盘旋转一周要6毫秒
RD=6ms/2=3ms
磁盘平均搜索时间是3ms，数据传输的平均延时是2ms，这样一次I/O操作的平均时间是：
3ms+3ms+2ms=8ms
IOPS=1000/8=125 这块磁盘的每秒IO数（IOPS）为125。所以对于10000RPM的磁盘来说它所能承受的IO操作在IOPS在120～150之间。如果系统的I/O请求超过这个值，就会使磁盘成为系统的瓶颈。
对与系统而言有两种不同种类的I/O压力，连续I/O和随机I/O。
连续I/O常常出现在企业级这样的应用中，需要连续的读取大量数据。这种系统的性能依靠它读取和移动数据的大小和快慢。我们用iostat来监控，会发现rKB/s,wKB/s会很高。
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/sda 0.00 12891.43 0.00 105.71 0.00 106080.00 0.00 53040.00 1003.46 1099.43 3442.43 26.49 280.00
从输出我们看到w/s=105,wKB/s=53040.所以53040/105=505KB per I/O.
对于随机I/O的系统来说性能的关注点不在搜传输数据的大小和速度，而是在磁盘的IOPS。这类系统的I/O请求比较小但是数量很大，如Web服务器和Mail服务器。他们的性能主要依赖每秒钟可处理的请求数：
# iostat -x 1
avg-cpu: %user %nice %sys %idle
2.04 0.00 97.96 0.00
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/sda 0.00 633.67 3.06 102.31 24.49 5281.63 12.24 2640.82 288.89 73.67 113.89 27.22 50.00
从输出我们看到w/s=102,wKB/s=2640.所以2640/102=23KB per I/O.
因此对于连续I/O系统来说我们要关注系统读取大量数据的能力即KB per request.对于随机I/O系统我们注重IOPS值.
