Linux系统性能监控——第4章 IO篇（下）

4.2. 监控 I/O

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

4.2.1. Calculating IO’s Per Second(译注:IOPS 的计算)

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

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

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

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

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

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

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

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

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

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

4.2.2. Random vs Sequential I/O(译注:随机/顺序 I/O)

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

4.2.2.1. Sequential I/O(译注:顺序IO)

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

# iostat -x 1

avg-cpu: %user   %nice   %sys    %idle
0.00      0.00    57.1 4  42.86

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 1  06080.00  0.00   53040.00 1003.46  1099.43  3442.43 26.49  280.00
/dev/sda1 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
/dev/sda2 0.00  12857.14 0.00 5.71   0.00    105782.86 0.00   52891.43 18512.00 559.14   780.00  490.00 280.00
/dev/sda3 0.00  34.29    0.00 100.00 0.00    297.14    0.00   148.57   2.97     540.29   594.57  24.00  240.00

avg-cpu: %user %nice %sys %idle
0.00 0.00 23.53 76.47

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  17320.59 0.00 102.94 0.00    142305.88 0.00   71152.94 1382.40  6975.29  952.29  28.57  294.12
/dev/sda1 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
/dev/sda2 0.00  16844.12 0.00 102.94 0.00    138352.94 0.00   69176.47 1344.00  6809.71  952.29  28.57  294.12
/dev/sda3 0.00  476.47   0.00 0.00   0.00    952.94    0.00   1976.47  0.00     165.59   0.00    0.00   276.47

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

rkB/s 除以 r/s

wkB/s 除以 w/s

53040/105 = 505KB per I/O

71152/102 = 697KB per I/O

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

4.2.2.2. Random I/O(译注:随机IO)

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

# 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
/dev/sda1 0.00   5.10  0.00 2.04  0.00  57.14   0.00   28.57   28.00  1.12  55.00 55.00 11.22
/dev/sda2 0.00 628.57 3.06 100.27 24.49 5224.49 12.24 2612.24 321.50 72.55 121.25 30.63 50.00
/dev/sda3 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
 
avg-cpu: %user %nice %sys %idle
2.15 0.00 97.85 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  41.94  6.45 130.98 51.61 352.69 25.81 3176.34 19.79  2.90    286.32 7.37 15.05
/dev/sda1 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
/dev/sda2 0.00 41.94  4.30 130.98 34.41 352.69 17.20 3176.34 21.18  2.90    320.00 8.24 15.05
/dev/sda3 0.00 0.00   2.15   0.00 17.20   0.00  8.60    0.00  8.00  0.00      0.00 0.00  0.00

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

2640/102 = 23KB per I/O

3176/130 = 24KB per I/O

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

4.2.3. When Virtual Memory Kills I/O

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

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

procs ———–memory———- —swap– —–io—- –system– —-cpu—-
r  b    swpd   free  buff  cache   si   so    bi    bo   in cs   us sy id wa
17  0     1250  3248 45820 1488472    30 132   992    0 2437 7657 23 50  0 23
11  0     1376  3256 45820 1488888    57 245   416    0 2391 7173 10 90  0 0
12  0     1582  1688 45828 1490228    63 131  1348   76 2432 7315 10 90  0 10
12  2     3981  1848 45468 1489824   185 56   2300   68 2478 9149 15 12  0 73
14  2     10385 2400 44484 1489732     0 87   1112   20 2515 11620 0 12  0 88
14  2     12671 2280 43644 1488816    76 51   1812  204 2546 11407 20 45 0 35

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

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

# iostat -x 1
 
avg-cpu: %user %nice %sys %idle
0.00  0.00 100.00 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   1766.67 4866.67 1700.00 38933.33 31200.00 19466.67 15600.00 10.68    6526.67  100.56  5.08  3333.33
/dev/sda1 0.00   933.33  0.00    0.00    0.00     7733.33  0.00     3866.67  0.00     20.00    2145.07 7.37  200.00
/dev/sda2 0.00   0.00    4833.33 0.00    38666.67 533.33   19333.33 266.67   8.11     373.33   8.07    6.90  87.00
/dev/sda3 0.00   833.33  33.33   1700.00 266.67   22933.33 133.33   11466.67 13.38    6133.33  358.46  11.35 1966.67

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

4.3. 结论

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

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

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

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

4.  监控磁盘慢需要比较wait time(await) 和 service time(svctm).

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