Linux System and Performance Monitoring(I/O篇)

6.0 I/O 监控介绍mysql

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

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

[root @monitor ~ ] # /usr/bin/time -v date
Fri Sep 25 16: 46: 35 CST 2009
Command being timed: "date"
User time (seconds ): 0.00
System time (seconds ): 0.00
Percent of CPU this job got: ? %
Elapsed ( wall clock ) time (h:mm:ss or m:ss ): 0: 00.00
Average shared text size (kbytes ): 0
Average unshared data size (kbytes ): 0
Average stack size (kbytes ): 0
Average total size (kbytes ): 0
Maximum resident set size (kbytes ): 0
Average resident set size (kbytes ): 0
Major (requiring I /O ) page faults: 0
Minor (reclaiming a frame ) page faults: 183
Voluntary context switches: 1
Involuntary context switches: 1
Swaps: 0
File system inputs: 0
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes ): 4096
Exit status: 0

6.2 Major and Minor Page Faults(译注:主要页错误和次要页错误)数据库

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

一旦内存页被映射进内存的buffer cache(buff)中,内核将尝试从内存中读取或写入,此时内核过程就是minor page fault(MnPF).与在磁盘上操做相比,MnPF 经过反复使用内存中的内存页就大大的缩短了内核时间.缓存

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

# /usr/bin/time -v evolution
Major (requiring I/O) page faults: 163
Minor (reclaiming a frame) page faults: 5918app

第二次再运行时,内核已经不须要进行MPF了,由于进程所需的数据已经在内存中:dom

# /usr/bin/time -v evolution
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 5581ide

6.3 The File Buffer Cache(译注:文件缓存区)

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

如下例子,是查看/proc/meminfo 文件:

[root @opt-001 ~ ] # cat /proc/meminfo
MemTotal:      4042656 kB
MemFree:         97600 kB
Buffers:        345260 kB
Cached:        2874712 kB
SwapCached:          0 kB
Active:        2494768 kB
Inactive:      1134932 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:      4042656 kB
LowFree:         97600 kB
SwapTotal:     8193140 kB
SwapFree:      8193040 kB
Dirty:            1252 kB
Writeback:           0 kB
AnonPages:      409484 kB
Mapped:        1253336 kB
Slab:           221056 kB
PageTables:      20172 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:  10214468 kB
Committed_AS:  2218724 kB
VmallocTotal: 34359738367 kB
VmallocUsed:    267224 kB
VmallocChunk: 34359469767 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
Hugepagesize:     2048 kB

能够看出,这个系统总计有4GB (Memtotal)的可用内存.当前的空闲内存为96MB (MemFree),有337 MB内存被分配磁盘写操做(Buffers),还有2.8 GB页用于读磁盘(Cached).

内核这样是经过MnPF机制,而不表明全部的页都是来自磁盘.经过以上部分,咱们不可能确认系统是否处于瓶颈中.

6.4 Type of Memory Pages

在Linux 内核中,memory pages有3种,分别是:

1,Read Pages - 这些页经过MPF 从磁盘中读入,并且是只读.这些页存在于Buffer Cache中以及包括不可以修改的静态文件,二进制文件,还有库文件.当内核须要它们时,将读取到内存中.若是内存不足,内核将释放它们回空闲列表中.程序再次请求时,则经过MPF 再次读回内存.

2,Dirty Pages - 这些页是内核在内存中已经被修改过的数据页.当这些页须要同步回磁盘上,由pdflush 负责写回磁盘.若是内存不足,kswapd (与pdflush 一块儿)将这些页写回到磁盘上并释放更多的内存.

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

6.5 Writing Data Pages Back to Disk

应用程序有不少选择能够写脏页回磁盘上,可经过I/O 调度器使用 fsync() 或 sync() 这样的系统函数来实现当即写回.若是应用程序没有调用以上函数,pdflush 进程会按期与磁盘进行同步.

# ps -ef | grep pdflush
root 186 6 0 18:04 ? 00:00:00 [pdflush]

7.0 监控 I/O

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

7.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 数得出.

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

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

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

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

[root @opt-001 mysql_db ] # iostat -x 1
Linux 2.6.18- 164.el5 (opt-001.jobkoo.com )       09 / 27 / 2009

avg-cpu:  %user   % nice %system %iowait  %steal   %idle
0.69    0.02    1.01    0.15    0.00   98.13

Device:         rrqm /s   wrqm /s   r /s   w /s   rsec /s   wsec /s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.15    36.28  0.75 12.11    27.35   387.62    32.25     0.31   24.33   0.54   0.69
sda1              0.00     0.00  0.00  0.00     0.00     0.00     9.99     0.00    5.29   4.43   0.00
sda2              0.10    17.08  0.40  6.56    10.18   189.16    28.65     0.07    9.96   0.47   0.33
sda3              0.00     0.00  0.00  0.00     0.00     0.00    46.30     0.00   20.87  20.60   0.00
sda4              0.00     0.00  0.00  0.00     0.00     0.00     2.00     0.00   17.20  17.20   0.00
sda5              0.04    19.21  0.36  5.55    17.16   198.46    36.49     0.24   41.25   0.74   0.44

avg-cpu:  %user   % nice %system %iowait  %steal   %idle
0.00    0.00    0.00    0.25    0.00   99.75

Device:         rrqm /s   wrqm /s   r /s   w /s   rsec /s   wsec /s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00    60.00  0.00 114.00     0.00  1392.00    12.21     0.44    3.85   0.16   1.80
sda1              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda2              0.00    36.00  0.00 83.00     0.00   952.00    11.47     0.38    4.61   0.16   1.30
sda3              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda4              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda5              0.00    24.00  0.00 31.00     0.00   440.00    14.19     0.06    1.81   0.16   0.50

avg-cpu:  %user   % nice %system %iowait  %steal   %idle
0.00    0.00    0.00    0.00    0.00  100.00

Device:         rrqm /s   wrqm /s   r /s   w /s   rsec /s   wsec /s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda1              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda2              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda3              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda4              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda5              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00

评估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 都在增长.

7.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值)

7.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 分区

首先利用fdisk -l查看一下系统swap是哪一个分区

[root @monitor ~ ] # fdisk -l

Disk /dev /sda: 320.0 GB, 320072933376 bytes
255 heads, 63 sectors /track, 38913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End      Blocks   Id  System
/dev /sda1   *           1          25      200781   83  Linux
/dev /sda2              26        5247    41945715   83  Linux
/dev /sda3            5248        5769     4192965   82  Linux swap / Solaris
/dev /sda4            5770       38913   266229180    5  Extended
/dev /sda5            5770       38913   26622914883  Linux

# iostat -x 1 sda3

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   833.33  33.33   1700.00 266.67   22933.33 133.33   11466.67 13.38    6133.33  358.46  11.35 1966.67
/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   933.33  0.00    0.00    0.00     7733.33  0.00     3866.67  0.00     20.00    2145.07 7.37  200.00

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

7.4 结论

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

1,当CPU 有等待I/O 状况时,那说明磁盘处于超负荷状态. 2,计算你的磁盘可以承受多大的IOPS 数. 3,肯定你的应用是属于随机或者顺序读取磁盘. 4,监控磁盘慢须要比较wait time(await) 和 service time(svctm). 5,监控swap 和系统分区,要确保virtual memory不是文件系统I/O 的瓶颈.

相关文章
相关标签/搜索