注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

Fly to the Sky!

很多人因为寂寞而错爱一个人,更多人因为错爱一个人而寂寞一生。

 
 
 

日志

 
 

Linux性能监控之IO篇【转】  

2010-03-04 15:44:45|  分类: 性能分析工具 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

IO系统是整个系统中最慢的部分,因为它需要真正的物理操作磁盘的转 动和检索。比起内存来要差几个数量级。Linux内核将硬盘IO分页,每一页的大小默认为4K。这时,内存和磁盘的读写以页为单位进行,这些页叫做内存页。用time命令可以检查页的大小:

# /usr/bin/time -v date

<snip>

Page size (bytes): 4096

<snip>

 

主要页错误(Major Page Faults)和次要页 错误(Minor Page Faults):

MPFMajor Page Faults)表示进程 需要的数据并不在内存中,需要从磁盘读取。

一旦内存页读入到内存的 缓冲区中,程序就在内存中读取或写入数据,叫做MnPFMinor Page Faults)。MnPF通过重复使用内存页而缩短了内核时间。Time命令可以显示一个进程中MPFMnPF的数量,在evolution程序第一次启动的时候会有很多MPF

# /usr/bin/time -v evolution

<snip>

Major (requiring I/O) page faults: 163

Minor (reclaiming a frame) page faults: 5918

<snip>

 

如果再次启动evolution程序,我们就看到MPF消失了,因为此时进程需要的数据已经全部在内存中了:

# /usr/bin/time -v evolution

<snip>

Major (requiring I/O) page faults: 0

Minor (reclaiming a frame) page faults: 5581

<snip>

 

当进程不断的进行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会成为系统的瓶颈。我们会用到工具topvmstatiostatsar等。每一个工具的输出都从不同的方面反映除系统的性能情况。

 

情况1:同一时间进行大量的I/O操作

   在这种情况时我们 会发现CPUwa时间百分比会上升,证明系统的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

 

    从这个输出我们可以看到CPU50%的 时间都在等待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操作都需要一定的时间,而且这些时间对于硬盘来说是确定的,它包含磁盘旋转的延时RDrotation delay)和磁头搜索时间DSdisk seek)。RD由磁盘转速(RPM)决定。RD是磁盘旋转一周所需时间的一半。如RPM10000.

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操作在IOPS120150之间。如果系统的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值.

  评论这张
 
阅读(829)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018