linux IO

磁盘I/O子系统是Linux系统中最慢的部分.这个主要是归于CPU到物理操作磁盘之间距离(译注:盘片旋转以及寻道).如果拿读取磁盘和内存的时间作比较就是分钟级到秒级，这就像7天和7分钟的区别.因此本质上，Linux内核就是要最低程度的降低I/O数.本章将诉述内核在磁盘和内存之间处理数据的这个过程中，哪些地方会产生I/O.

6.1读和写数据-内存页

Linux内核将硬盘I/O进行分页，多数Linux系统的默认页大小为4K.读和写磁盘块进出到内存都为4K页大小.你可以使用time这个命令加-v参数，来检查你系统中设置的页大小:

#/usr/bin/time-vdate

Pagesize(bytes):4096

6.2MajorandMinorPageFaults(译注:主要页错误和次要页错误)

Linux，类似多数的UNIX系统，使用一个虚拟内存层来映射硬件地址空间.当一个进程被启动，内核先扫描CPUcaches和物理内存.如果进程需要的数据在这2个地方都没找到，就需要从磁盘上读取，此时内核过程就是majorpagefault(MPF).MPF要求磁盘子系统检索页并缓存进RAM.

一旦内存页被映射进内存的buffercache(buff)中，内核将尝试从内存中读取或写入，此时内核过程就是minorpagefault(MnPF).与在磁盘上操作相比，MnPF通过反复使用内存中的内存页就大大的缩短了内核时间.

以下的例子，使用time命令验证了，当进程启动后，MPF和MnPF的变化情况.第一次运行进程，MPF会更多:

#/usr/bin/time-vevolution

Major(requiringI/O)pagefaults:163

Minor(reclaimingaframe)pagefaults:5918

第二次再运行时，内核已经不需要进行MPF了，因为进程所需的数据已经在内存中:

#/usr/bin/time-vevolution

Major(requiringI/O)pagefaults:0

Minor(reclaimingaframe)pagefaults:5581

6.3TheFileBufferCache(译注:文件缓存区)

文件缓存区就是指，内核将MPF过程最小化，MnPF过程最大化.随着系统不断的产生I/O，buffercache也将不断的增加.直到内存不够，以及系统需要释放老的内存页去给其他用户进程使用时，系统就会丢弃这些内存页.结果是，很多sa(译注:系统管理员)对系统中过少的freememory(译注:空闲内存)表示担心，实际上这是系统更高效的在使用caches.

以下例子，是查看/proc/meminfo文件:

#cat/proc/meminfo

MemTotal:2075672kB

MemFree:52528kB

Buffers:24596kB

Cached:1766844kB

可以看出，这个系统总计有2GB(Memtotal)的可用内存.当前的空闲内存为52MB(MemFree)，有24MB内存被分配磁盘写操作(Buffers)，还有1.7GB页用于读磁盘(Cached).

内核这样是通过MnPF机制，而不代表所有的页都是来自磁盘.通过以上部分，我们不可能确认系统是否处于瓶颈中.

6.4TypeofMemoryPages

在Linux内核中，memorypages有3种，分别是:

1，ReadPages-这些页通过MPF从磁盘中读入，而且是只读.这些页存在于BufferCache中以及包括不能够修改的静态文件，二进制文件，还有库文件.当内核需要它们时，将读取到内存中.如果内存不足，内核将释放它们回空闲列表中.程序再次请求时，则通过MPF再次读回内存.

2，DirtyPages-这些页是内核在内存中已经被修改过的数据页.当这些页需要同步回磁盘上，由pdflush负责写回磁盘.如果内存不足，kswapd(与pdflush一起)将这些页写回到磁盘上并释放更多的内存.

3，AnonymousPages-这些页属于某个进程，但是没有任何磁盘文件和它们有关.他们不能和同步回磁盘.如果内存不足，kswapd将他们写入swap分区上并释放更多的内存("swapping"pages).

6.5将数据页写回磁盘

应用程序有很多选择可以写脏页回磁盘上，可通过I/O调度器使用fsync()或sync()这样的系统函数来实现立即写回.如果应用程序没有调用以上函数，pdflush进程会定期与磁盘进行同步.

#ps-ef|greppdflush

root1866018:04?00:00:00[pdflush]

7.0监控I/O

当觉得系统中出现了I/O瓶颈时，可以使用标准的监控软件来查找原因.这些工具包括了top，vmstat，iostat，sar.它们的输出结果一小部分是很相似，不过每个也都提供了各自对于性能不同方面的解释.以下章节就将讨论哪些情况会导致I/O瓶颈的出现.

7.1CalculatingIO'sPerSecond(译注:IOPS的计算)

每个I/O请求到磁盘都需要若干时间.主要是因为磁盘的盘边必须旋转，机头必须寻道.磁盘的旋转常常被称为"rotationaldelay"(RD)，机头的移动称为"diskseek"(DS).一个I/O请求所需的时间计算就是DS加上RD.磁盘的RD基于设备自身RPM单位值(译注:RPM是RevolutionsPerminute的缩写，是转/每分钟，代表了硬盘的转速).一个RD就是一个盘片旋转的

半圆.如何计算一个10KRPM设备的RD值呢:

1，10000RPM/60seconds(10000/60=166RPS)

2，转换为166分之1的值(1/166=0.006seconds/Rotation)

3，单位转换为毫秒(6MS/Rotation)

4，旋转半圆的时间(6/2=3MS)也就是RD

5，加上平均3MS的寻道时间(3MS+3MS=6MS)

6，加上2MS的延迟(6MS+2MS=8MS)

7，1000MS/8MS(1000/8=125IOPS)

每次应用程序产生一个I/O，在10KRPM磁盘上都要花费平均8MS.在这个固定时间里，磁盘将尽可能且有效率在进行读写磁盘.IOPS可以计算出大致的I/O请求数，10KRPM磁盘有能力提供120-150次IOPS.评估IOPS的效能，可用每秒读写I/O字节数除以每秒读写IOPS数得出.

7.2RandomvsSequentialI/O(译注:随机/顺序I/O)

perI/O产生的KB字节数是与系统本身workload相关的，有2种不同workload的类型，它们是sequential和random.

7.2.1SequentialI/O(译注:顺序IO)

iostat命令提供信息包括IOPS和每个I/O数据处理的总额.可使用iostat-x查看.顺序的workload是同时读顺序请求大量的数据.这包括的应用，比如有商业数据库(database)在执行大量的查询和流媒体服务.在这个workload中，KBperI/O的比率应该是很高的.Sequentialworkload是可以同时很快的移动大量数据.如果每个I/O都节省了时间，那就意味了能带来更多的数据处理.

#iostat-x1

avg-cpu:%user%nice%sys%idle

0.000.0057.1442.86

Device:rrqm/swrqm/sr/sw/srsec/swsec/srkB/swkB/savgrq-szavgqu-szawaitsvctm%util

/dev/sda0.0012891.430.00105.710.00106080.000.0053040.001003.461099.433442.4326.49280.00

/dev/sda10.000.000.000.000.000.000.000.000.000.000.000.000.00

/dev/sda20.0012857.140.005.710.00105782.860.0052891.4318512.00559.14780.00490.00280.00

/dev/sda30.0034.290.00100.000.00297.140.00148.572.97540.29594.5724.00240.00

avg-cpu:%user%nice%sys%idle

0.000.0023.5376.47

Device:rrqm/swrqm/sr/sw/srsec/swsec/srkB/swkB/savgrq-szavgqu-szawaitsvctm%util

/dev/sda0.0017320.590.00102.940.00142305.880.0071152.941382.406975.29952.2928.57294.12

/dev/sda10.000.000.000.000.000.000.000.000.000.000.000.000.00

/dev/sda20.0016844.120.00102.940.00138352.940.0069176.471344.006809.71952.2928.57294.12

/dev/sda30.00476.470.000.000.00952.940.001976.470.00165.590.000.00276.47

评估IOPS的效能，可用每秒读写I/O字节数除以每秒读写IOPS数得出，比如

rkB/s除以r/s

wkB/s除以w/s

53040/105=505KBperI/O

71152/102=697KBperI/O

在上面例子可看出，每次循环下，/dev/sda的perI/O都在增加.

7.2.2RandomI/O(译注:随机IO)

Random的worklaod环境下，不依赖于数据大小的多少，更多依赖的是磁盘的IOPS数.Web和Mail服务就是典型的Randomworkload.I/O请求内容都很小.Randomworkload是同时每秒会有更多的请求数产生.所以，磁盘的IOPS数是关键.

#iostat-x1

avg-cpu:%user%nice%sys%idle

2.040.0097.960.00

Device:rrqm/swrqm/sr/sw/srsec/swsec/srkB/swkB/savgrq-szavgqu-szawaitsvctm%util

/dev/sda0.00633.673.06102.3124.495281.6312.242640.82288.8973.67113.8927.2250.00

/dev/sda10.005.100.002.040.0057.140.0028.5728.001.1255.0055.0011.22

/dev/sda20.00628.573.06100.2724.495224.4912.242612.24321.5072.55121.2530.6350.00

/dev/sda30.000.000.000.000.000.000.000.000.000.000.000.000.00

avg-cpu:%user%nice%sys%idle

2.150.0097.850.00

Device:rrqm/swrqm/sr/sw/srsec/swsec/srkB/swkB/savgrq-szavgqu-szawaitsvctm%util

/dev/sda0.0041.946.45130.9851.61352.6925.813176.3419.792.90286.327.3715.05

/dev/sda10.000.000.000.000.000.000.000.000.000.000.000.000.00

/dev/sda20.0041.944.30130.9834.41352.6917.203176.3421.182.90320.008.2415.05

/dev/sda30.000.002.150.0017.200.008.600.008.000.000.000.000.00

计算方式和之前的公式一致:

2640/102=23KBperI/O

3176/130=24KBperI/O

(译注:对于顺序I/O来说，主要是考虑读取大量数据的能力即KBperrequest.对于随机I/O系统，更需要考虑的是IOPS值)

7.3WhenVirtualMemoryKillsI/O

如果系统没有足够的RAM响应所有的请求，就会使用到SWAPdevice.就像使用文件系统I/O，使用SWAPdevice代价也很大.如果系统已经没有物理内存可用，那就都在SWAPdisk上创建很多很多的内存分页，如果同一文件系统的数据都在尝试访问SWAPdevice，那系统将遇到I/O瓶颈.最终导致系统性能的全面崩溃.如果内存页不能够及时读或写磁盘，它们就一直保留在RAM中.如果保留时间太久，内核又必须释放内存空间.问题来了，I/O操作都被阻塞住了，什么都没做就被结束了，不可避免地就出现kernelpanic和systemcrash.

下面的vmstat示范了一个内存不足情况下的系统:

procs-----------memory-------------swap-------io------system------cpu----

rbswpdfreebuffcachesisobiboincsussyidwa

17012503248458201488472301329920243776572350023

1101376325645820148888857245416023917173109000

1201582168845828149022863131134876243273151090010

1223981184845468148982418556230068247891491512073

142103852400444841489732087111220251511620012088

142126712280436441488816765118122042546114072045035

这个结果可看出，大量的读请求回内存(bi)，导致了空闲内存在不断的减少(free).这就使得系统写入swapdevice的块数目(so)和swap空间(swpd)在不断增加.同时看到CPUWIOtime(wa)百分比很大.这表明I/O请求已经导致CPU开始效率低下.

要看swaping对磁盘的影响，可使用iostat检查swap分区

#iostat-x1

avg-cpu:%user%nice%sys%idle

0.000.00100.000.00

Device:rrqm/swrqm/sr/sw/srsec/swsec/srkB/swkB/savgrq-szavgqu-szawaitsvctm%util

/dev/sda0.001766.674866.671700.0038933.3331200.0019466.6715600.0010.686526.67100.565.083333.33

/dev/sda10.00933.330.000.000.007733.330.003866.670.0020.002145.077.37200.00

/dev/sda20.000.004833.330.0038666.67533.3319333.33266.678.11373.338.076.9087.00

/dev/sda30.00833.3333.331700.00266.6722933.33133.3311466.6713.386133.33358.4611.351966.67

在这个例子中，swapdevice(/dev/sda1)和filesystemdevice(/dev/sda3)在互相作用于I/O.其中任一个会有很高写请求(w/s)，也会有很高waittime(await)，或者较低的服务时间比率(svctm).这表明2个分区之间互有联系，互有影响.

7.4结论

I/O性能监控包含了以下几点:

1，当CPU有等待I/O情况时，那说明磁盘处于超负荷状态.

2，计算你的磁盘能够承受多大的IOPS数.

3，确定你的应用是属于随机或者顺序读取磁盘.

4，监控磁盘慢需要比较waittime(await)和servicetime(svctm).

5，监控swap和系统分区，要确保virtualmemory不是文件系统I/O的瓶颈.