Linux系统瓶颈分析(经典!).pdf

1.0性能监控介绍 性能优化就是找到系统处理中的瓶颈以及去除这些的过程,多数管理员相信看一些相关的cookbook就可以实现性能优化,通常通过对内核的一些配置是可以简单的解决问题,但并不适合每个环境,性能优化其实是对OS各子系统达到一种平衡的定义,这些子系统包括了:CPU Memory IO Network这些子系统之间关系是相互彼此依赖的,任何一个高负载都会导致其他子系统出现问题.比如:大量的页调入请求导致内存队列的拥塞 网卡的大吞吐量可能导致更多的 CPU开销 大量的CPU开销又会尝试更多的内存使用请求 大量来自内存的磁盘写请求可能导致更多的 CPU以及 IO问题 所以要对一个系统进行优化,查找瓶颈来自哪个方面是关键,虽然看似是某一个子系统出现问题,其实有可能是别的子系统导致的.1.1确定应用类型 基于需要理解该从什么地方来入手优化瓶颈,首先重要的一点,就是理解并分析当前系统的特点,多数系统所跑的应用类型,主要为2种:IOBound(IO范畴):在这个范畴中的应用,一般都是高负荷的内存使用以及存储系统,这实际上表示IO范畴的应用,就是一个大量数据处理的过程.IO范畴的应用不对CPU以及网络发起更多请求(除非类似NAS这样的网络存储硬件).IO范畴的应用通常使用CPU资源都是为了产生IO请求以及进入到内核调度的sleep状态.通常数据库软件(例如mysql,oracle等)被认为是IO范畴的应用类型.CPUBound(CPU范畴):在这个范畴中的应用,一般都是高负荷的CPU占用.CPU范畴的应用,就是一个批量处理CPU请求以及数学计算的过程.通常webserver,mailserver,以及其他类型服务被认为是CPU范畴的应用类型.1.2确定基准线统计 系统利用率情况,一般随管理员经验以及系统本身用途来决定.唯一要清楚的就是,系统优化希望达成什么效果,以及哪些方面是需要优化,还有参考值是什么?因此就建立一个基准线,这个统计数据必须是系统可用性能状态值,用来比较不可用性能状态值.在以下例子中,1个系统性能的基准线快照,用来比较当高负荷时的系统性能快照.#vmstat1procsmemoryswapiosystemcpurbswpdfreebuffcachesisobiboincsussywaid10138592179321262722142440011810919211960013859217932126272214244000010546010990013859217932126272214244000019862401404500138592179321262722142440000117490001000013859217924126272214244000176220938341380001385921792412627221424400003581522817075101385921792412627221424400003681447424072001385921792412627221424400003521277912079#vmstat1procsmemoryswapiosystemcpurbswpdfreebuffcachesisobiboincsussywaid2014594017752118600215592011181091921196201459401585611860421565200046878910886140030146208138841186002146400360036049871919002014638813764118600213788034003406724187130020147092137881186002124520740013246206192800201473601384811860021158007200720690419640020147912137441181922105920720072060544955002014845213900118192209260037203726394581190020149132136921178242084120372037245747901000从上面第一个结果可看到,最后一列(id)表示的是空闲时间,我们可以看到,在基准线统计时,CPU的空闲时间在79%100%.在第二个结果可看到,系统处于100%的占用率以及没有空闲时间.从这个比较中,我们就可以确定是否是CPU使用率应该被优化.2.0安装监控工具 多数*nix系统都有一堆标准的监控命令.这些命令从一开始就是*nix的一部分.Linux则通过基本安装包以及额外包提供了其他监控工具,这些安装包多数都存在各个Linux发布版本中.尽管还有其他更多的开源以及第三方监控软件,但本文档只讨论基于Linux发布版本的监控工具.本章将讨论哪些工具怎样来监控系统性能.3.0CPU介绍 CPU利用率主要依赖于是什么资源在试图存取.内核调度器将负责调度2种资源种类:线程(单一或者多路)和中断.调度器去定义不同资源的不同优先权.以下列表从优先级高到低排列:Interrupts(中断)设备通知内核,他们完成一次数据处理的过程.例子,当一块网卡设备递送网络数据包或者一块硬件提供了一次IO请求.Kernel(System)Processes(内核处理过程)所有内核处理过程就是控制优先级别.UserProcesses(用户进程)这块涉及userland.所有软件程序都运行在这个userspace.这块在内核调度机制中处于低优先级.从上面,我们可以看出内核是怎样管理不同资源的.还有几个关键内容需要介绍,以下部分就将介绍context(上下文切换),runqueues(运行队列)以及utilization(利用率).3.1上下文切换 多数现代处理器都能够运行一个进程(单一线程)或者线程.多路超线程处理器有能力运行多个线程.然而,Linux内核还是把每个处理器核心的双核心芯片作为独立的处理器.比如,以Linux内核的系统在一个双核心处理器上,是报告显示为两个独立的处理器.一个标准的Linux内核可以运行50至 50,000的处理线程.在只有一个CPU时,内核将调度并均衡每个进程线程.每个线程都分配一个在处理器中被开销的时间额度.一个线程要么就是获得时间额度或已抢先获得一些具有较高优先级(比如硬件中断),其中较高优先级的线程将从区域重新放置回处理器的队列中.这种线程的转换关系就是我们提到的上下文切换.每次内核的上下文切换,资源被用于关闭在CPU寄存器中的线程和放置在队列中.系统中越多的上下文切换,在处理器的调度管理下,内核将得到更多的工作.3.2运行队列 每个CPU都维护一个线程的运行队列.理论上,调度器应该不断的运行和执行线程.进程线程不是在sleep状态中(阻塞中和等待IO中)或就是在可运行状态中.如果CPU子系统处于高负荷下,那就意味着内核调度将无法及时响应系统请求.导致结果,可运行状态进程拥塞在运行队列里.当运行队列越来越巨大,进程线程将花费更多的时间获取被执行.比较流行的术语就是load,它提供当前运行队列的详细状态.系统 load就是指在CPU队列中有多少数目的线程,以及其中当前有多少进程线程数目被执行的组合.如果一个双核系统执行了2个线程,还有4个在运行队列中,则 load应该为 6.top这个程序里显示的loadaverages是指1,5,15分钟以内的load情况.3.3CPU利用率 CPU利用率就是定义CPU使用的百分比.评估系统最重要的一个度量方式就是CPU的利用率.多数性能监控工具关于CPU利用率的分类有以下几种:UserTime(用户进程时间)关于在userspace中被执行进程在CPU开销时间百分比.SystemTime(内核线程以及中断时间)关于在kernelspace中线程和中断在CPU开销时间百分比.WaitIO(IO请求等待时间)所有进程线程被阻塞等待完成一次IO请求所占CPU开销idle的时间百分比.Idle(空闲)一个完整空闲状态的进程在CPU处理器中开销的时间百分比.4.0CPU性能监控 理解运行队列,利用率,上下文切换对怎样CPU性能最优化之间的关系.早期提及到,性能是相对于基准线数据的.在一些系统中,通常预期所达到的性能包括:RunQueues每个处理器应该运行队列不超过13个线程.例子,一个双核处理器应该运行队列不要超过6个线程.CPUUtiliation如果一个CPU被充分使用,利用率分类之间均衡的比例应该是 65%70%UserTime30%35%SystemTime0%5%IdleTimeContextSwitches上下文切换的数目直接关系到CPU的使用率,如果CPU利用率保持在上述均衡状态时,大量的上下文切换是正常的.很多Linux上的工具可以得到这些状态值,首先就是 vmstat和 top这2个工具.4.1vmstat工具的使用 vmstat工具提供了一种低开销的系统性能观察方式.因为 vmstat本身就是低开销工具,在非常高负荷的服务器上,你需要查看并监控系统的健康情况,在控制窗口还是能够使用vmstat输出结果.这个工具运行在2种模式下:average和 sample模式.sample模式通过指定间隔时间测量状态值.这个模式对于理解在持续负荷下的性能表现,很有帮助.下面就是 vmstat运行1秒间隔的示例:#vmstat1procsmemoryswapiosystemcpurbswpdfreebuffcachesisobiboincsussyidwa00104300168009532872200005267144195000104300168009532872200000241021641198000104300168009532872200000010095911980 ThevmstatCPUstatistics FieldDescription rTheamountofthreadsintherunqueue.Thesearethreadsthatarerunnable,buttheCPUisnotavailabletoexecutethem.当前运行队列中线程的数目.代表线程处于可运行状态,但CPU还未能执行.bThisisthenumberofprocessesblockedandwaitingonIOrequeststofinish.当前进程阻塞并等待IO请求完成的数目 inThisisthenumberofinterruptsbeingprocessed.当前中断被处理的数目 csThisisthenumberofcontextswitchescurrentlyhappeningonthesystem.当前kernelsystem中,发生上下文切换的数目 usThisisthepercentageofuserCPUutilization.CPU利用率的百分比 sysThisisthepercentageofkernelandinterruptsutilization.内核和中断利用率的百分比 waThisisthepercentageofidleprocessortimeduetothefactthatALLrunnablethreadsareblockedwaitingonIO.所有可运行状态线程被阻塞在等待IO请求的百分比 idThisisthepercentageoftimethattheCPUiscompletelyidle.CPU空闲时间的百分比 4.2案例学习:持续的CPU利用率 在这个例子中,这个系统被充分利用#vmstat1procsmemoryswapiosystemcpurbswpdfreebuffcachesisobiboincsussywaid302065641509280336176080000071826811900202065641477280336176120000075823964001020656414208803361761360000820209640010206956138847918017596404120268010088093700202073481444878800175576041204127637084160020207348157567880017542400008742589110010207348163687880017559600009402486140010207348166007880017560400009292795302302073481697678548175876000250896935937004020734816216785481757040000874369360140207348164247854817577600008502677230020207348174967855617584000007362383170000207348176807855617586800008612191801根据观察值,我们可以得到以下结论:1,有大量的中断(in)和较少的上下文切换(cs).这意味着一个单一的进程在产生对硬件设备的请求.2,进一步显示某单个应用,usertime(us)经常在85%或者更多.考虑到较少的上下文切换,这个应用应该还在处理器中被处理.3,运行队列还在可接受的性能范围内,其中有2个地方,是超出了允许限制.4.3案例学习:超负荷调度 在这个例子中,内核调度中的上下文切换处于饱和#vmstat1procsmemoryswapiosystemcpurbswpdfreebuffcachesisobiboincsussywaid21207740984768134418097200249609002883412572701207740964488330418098400196832881025598983001207740944048534818098400204408292879967870120774092576871761809840018280689208839781020207740913008845218098400127605652182768343120774090124896281809840011760551221927910422077408924090512180984008805204439072210670532077408805691680180984001168062812481211770422077408685292880180984001200065415056787061207740857369399618098400111605261512510850012077408484494888180984008920438155664900根据观察值,我们可以得到以下结论:1,上下文切换数目高于中断数目,说明kernel中相当数量的时间都开销在上下文切换线程.2,大量的上下文切换将导致CPU利用率分类不均衡.很明显实际上等待io请求的百分比(wa)非常高,以及usertime百分比非常低(us).3,因为CPU都阻塞在IO请求上,所以运行队列里也有相当数目的可运行状态线程在等待执行.4.4mpstat工具的使用 如果你的系统运行在多处理器芯片上,你可以使用 mpstat命令来监控每个独立的芯片.Linux内核视双核处理器为2CPUs,因此一个双核处理器的双内核就报告有4CPUs可用.mpstat命令给出的CPU利用率统计值大致和 vmstat一致,但是 mpstat可以给出基于单个处理器的统计值.#mpstatPALL1Linux2.4.2120.ELsmp(localhost.localdomain)05/23/200605:17:31PMCPU%user%nice%system%idleintr/s05:17:32PMall0.000.003.1996.5313.2705:17:32PM00.000.000.00100.000.0005:17:32PM11.120.0012.7386.1513.2705:17:32PM20.000.000.00100.000.0005:17:32PM30.000.000.00100.000.004.5案例学习:未充分使用的处理量 在这个例子中,为4CPU核心可用.其中2个CPU主要处理进程运行(CPU0和1).第3个核心处理所有内核和其他系统功能(CPU3).第4个核心处于idle(CPU2).使用 top命令可以看到有3个进程差不多完全占用了整个CPU核心.#topd1top23:08:53up8:34,3users,loadaverage:0.91,0.37,0.13Tasks:190total,4running,186sleeping,0stopped,0zombieCpu(s):75.2%us,0.2%sy,0.0%ni,24.5%id,0.0%wa,0.0%hi,0.0%siMem:2074736ktotal,448684kused,1626052kfree,73756kbuffersSwap:4192956ktotal,0kused,4192956kfree,259044kcachedPIDUSERPRNIVIRTRESSHRS%CPU%MEMTIME+COMMAND15957nobody2502776280224R10020.50:25.48php15959mysql2502256280224R10038.20:17.78mysqld15960apache2502416280224R10015.70:11.20httpd15901root16027801092800R10.10:01.59top1root1601780660572S00.00:00.64init#mpstatPALL1Linux2.4.2120.ELsmp(localhost.localdomain)05/23/200605:17:31PMCPU%user%nice%system%idleintr/s05:17:32PMall81.520.0018.4821.17130.5805:17:32PM083.670.0017.350.00115.3105:17:32PM180.610.0019.390.0013.2705:17:32PM20.000.0016.3384.662.0105:17:32PM379.590.0021.430.000.0005:17:32PMCPU%user%nice%system%idleintr/s05:17:33PMall85.860.0014.1425.00116.4905:17:33PM088.660.0012.370.00116.4905:17:33PM180.410.0019.590.000.0005:17:33PM20.000.000.00100.000.0005:17:33PM383.510.0016.490.000.0005:17:33PMCPU%user%nice%system%idleintr/s05:17:34PMall82.740.0017.2625.00115.3105:17:34PM085.710.0013.270.00115.3105:17:34PM178.570.0021.430.000.0005:17:34PM20.000.000.00100.000.0005:17:34PM392.860.009.180.000.0005:17:34PMCPU%user%nice%system%idleintr/s05:17:35PMall87.500.0012.5025.00115.3105:17:35PM091.840.008.160.00114.2905:17:35PM190.820.0010.200.001.0205:17:35PM20.000.000.00100.000.0005:17:35PM381.630.0015.310.000.00你也可以使用 ps命令通过查看 PSR这列,检查哪个进程在占用了哪个CPU.#while:;dopseopid,ni,pri,pcpu,psr,comm|grepmysqld;sleep1;donePIDNIPRI%CPUPSRCOMMAND1577501586.03mysqldPIDNIPRI%CPUPSRCOMMAND1577501494.03mysqldPIDNIPRI%CPUPSRCOMMAND1577501496.63mysqldPIDNIPRI%CPUPSRCOMMAND1577501498.03mysqldPIDNIPRI%CPUPSRCOMMAND1577501498.83mysqldPIDNIPRI%CPUPSRCOMMAND1577501499.33mysqld4.6结论 监控 CPU性能由以下几个部分组成:1,检查system的运行队列,以及确定不要超出每个处理器3个可运行状态线程的限制.2,确定CPU利用率中user/system比例维持在70/303,当CPU开销更多的时间在systemmode,那就说明已经超负荷并且应该尝试重新调度优先级 4,当I/O处理得到增长,CPU范畴的应用处理将受到影响 5.0VirtualMemory介绍 虚拟内存就是采用硬盘对物理内存进行扩展,所以对可用内存的增加是要相对在一个有效范围内的.内核会写当前未使用内存块的内容到硬盘上,此时这部分内存被用于其它用途.当再一次需要原始内容时,此时再读回到内存中.这对于用户来说,是完全透明的;在Linux下运行的程序能够看到,也仅仅是大量的可用内存,同时也不会留意到,偶尔还有部分是驻留在磁盘上的.当然,在硬盘上进行读和写,都是很慢的(大约会慢上千倍),相对于使用真实内存的话,因此程序无法运行的更快.用硬盘的一部分作为VirtualMemory,这就被称为swapspace(交换空间).5.1VirtualMemoryPages虚拟内存被分为很多 pages(页),在X86架构中,每个虚拟内存页为 4KB.当内核写内存到磁盘或者读磁盘到内存,这就是一次写内存到页的过程.内核通常是在swap分区和文件系统之间进行这样的操作.5.2KernelMemoryPaging内存分页在正常情况下总是活跃的,与memoryswapping(内存交换)之间不要搞错了.内存分页是指内核会定期将内存中的数据同步到硬盘,这个过程就是MemoryPaging.日复一日,应用最终将会消耗掉所有的内存空间.考虑到这点,内核就必须经常扫描内存空间并且收回其中未被使用的内存页,然后再重新分配内存空间给其他应用使用.5.3ThePageFrameReclaimAlgorithm(PFRA)(页框回收算法)PFRA就是OS内核用来回收并释放内存空间的算法.PFRA选择哪个内存页被释放是基于内存页类型的.页类型有以下几种:Unreclaimable锁定的，内核保留的页面 Swappable匿名的内存页 Syncable通过硬盘文件备份的内存页 Discardable静态页和被丢弃的页 除了第一种（Unreclaimable）之外其余的都可以被PFRA进行回收.与PFRA相关的,还包括kswapd内核线程以及LowOnMemoryReclaiming(LMR算法)这2种进程和实现.5.4kswapdkswapd进程负责确保内存空间总是在被释放中.它监控内核中的pages_high和pages_low阀值.如果空闲内存的数值低于 pages_low,则每次 kswapd进程启动扫描并尝试释放32个freepages.并一直重复这个过程,直到空闲内存的数值高于 pages_high.kswapd进程完成以下几个操作:1,如果该页处于未修改状态,则将该页放置回空闲列表中.2,如果该页处于已修改状态并可备份回文件系统,则将页内容写入到磁盘.3,如果该页处于已修改状态但没有任何磁盘备份,则将页内容写入到swapdevice.#psef|grepkswapdroot301023:01?00:00:00kswapd05.5KernelPagingwithpdflushpdflush进程负责将内存中的内容和文件系统进行同步操作.也就是说,当一个文件在内存中进行修改后,pdflush将负责写回到磁盘上.#psef|greppdflushroot283023:01?00:00:00pdflushroot293023:01?00:00:00pdflush当内存中存在10%的脏页,pdflush将被启动同步脏页回文件系统里.这个参数值可以通过 vm.dirty_background_ratio来进行调整.(Q:什么是脏页?A:由于内存中页缓存的缓存作用,写操作实际上都是延迟的.当页缓存中的数据比磁盘存储的数据还要更新时,那么该数据就被称做脏页.)#sysctlnvm.dirty_background_ratio10在多数环境下,Pdflush与PFRA是独立运行的,当内核调用LMR时,LMR就触发pdflush将脏页写入到磁盘里.+在2.4内核下,一个高负荷的内存环境中,系统将遇到交换过程中不断的崩溃.这是因为PFRA从一个运行进程中,偷取其中一个内存页并尝试使用.导致结果就是,这个进程如果要回收那个页时,要是没有就会尝试再去偷取这个页,这样一来,就越来越糟糕了.在2.6内核下,使用Swaptoken修复了这个BUG,用来防止PFRA不断从一个进程获取同一个页.+5.6案例学习:大量的入口I/Ovmstat工具报告里除了CPU使用情况,还包括了虚拟内存.以下就是vmstat输出中关于虚拟内存的部分:Table2:ThevmstatMemoryStatisticsFieldDescriptionSwapdTheamountofvirtualmemoryinKBcurrentlyinuse.Asfreememoryreacheslowthresholds,moredataispagedtotheswapdevice.当前虚拟内存使用的总额(单位:KB).空闲内存达到最低的阀值时,更多的数据被转换成页到交换设备中.FreeTheamountofphysicalRAMinkilobytescurrentlyavailabletorunningapplications.当前内存中可用空间字节数.BuffTheamountofphysicalmemoryinkilobytesinthebuffercacheasaresultofread()andwrite()operations.当前内存中用于read()和write()操作的缓冲区中缓存字节数 CacheTheamountofphysicalmemoryinkilobytesmappedintoprocessaddressspace.当前内存中映射到进程地址空间字节数 SoTheamountofdatainkilobyteswrittentotheswapdisk.写入交换空间的字节数总额 SiTheamountofdatainkilobyteswrittenfromtheswapdiskbackintoRAM.从交换空间写回内存的字节数总额 BoTheamountofdiskblockspagedoutfromtheRAMtothefilesystemorswapdevice.磁盘块页面从内存到文件或交换设备的总额 BiTheamountofdiskblockspagedintoRAMfromthefilesystemorswapdevice.磁盘块页面从文件或交换设备到内存的总额 以下 vmstat的输出结果,就是演示一个在I/O应用中,虚拟内存在高负荷情况下的环境#vmstat3procsmemoryswapiosystemcpurbswpdfreebuffcachesisobiboincsussyidwa32809192261556797608868804160824475142686317367503809188194916798209529003070217451005118925903461248038091881622127984098892095012107018012633223941380926888756799241061424260281837711311421694353881282628417608712401144180100614025839163801528117919912612185478017688341401208980195352555730967176422384313162808867528175883233212263923143841652427808149016344110743428773721759632372122753221332811091233376789323373571288598017800324081239160204289212347126811033982401224652900472179803244012538842448511752148569341730481213261190440417620324921258928151316764715804919978499172541911192179443254012667243722631290735478341421471420201191929217876318241275832127451632727476171421521123145092521617812250081289320121975127603181772125450102119059328601773621760130028082556154693873825125849132415根据观察值,我们可以得到以下结论:1,大量的磁盘块页面来自文件系统(bi),很明显在进程地址空间里,数据缓存在不断的增长.2,在这个时间点上,空闲内存(free)始终保持在17MB,即使数据是从磁盘到分页而在消耗空闲RAM.3,为了维护空闲列表,kswapd从读/写缓存区(buff)中获取内存并分配到空闲列表里.很明显可以看到buffercache(buff)在逐渐的减少中.4,kswapd进程当写脏页到交换设备(so)时,很明显虚拟内存的利用率是逐渐的增加中(swpd).5.7结论 监控虚拟内存性能由以下几个部分组成:1,当系统中出现较重大的页错误,要获得最好的响应时间,就要使得memorycaches(内存高速缓存)超过diskcaches(磁盘高速缓存).2,较少的空闲内存,是件好事情,那意味着缓存的使用更有效率.除非在不断的写入swapdevice(交换设备)和disk(硬盘).3,如果系统不断报告,swapdevice总是繁忙中,那就意味着内存已经不足,需要升级了.6.0I/O监控介绍 磁盘I/O子系统是Linux系统中最慢的部分.这个主要是归于CPU到物理操作磁盘之间距离(盘片旋转以及寻道).如果拿读取磁盘和内存的时间作比较就是分钟级到秒级,这就像 7天和7分钟的区别.因此本质上,Linux内核就是要最低程度的降低I/O数.本章将诉述内核在磁盘和内存之间处理数据的这个过程中,哪些地方会产生I/O.6.1读和写数据 内存页 Linux内核将硬盘I/O进行分页,多数Linux系统的默认页大小为4K.读和写磁盘块进出到内存都为4K页大小.你可以使用time这个命令加v参数,来检查你系统中设置的页大小:#/usr/bin/timevdate2009年 08月 13日 星期四 23:07:59CSTCommandbeingtimed:dateUsertime(seconds):0.00Systemtime(seconds):0.00PercentofCPUthisjobgot:200%Elapsed(wallclock)time(h:mm:ssorm:ss):0:00.00Averagesharedtextsize(kbytes):0Averageunshareddatasize(kbytes):0Averagestacksize(kbytes):0Averagetotalsize(kbytes):0Maximumresidentsetsize(kbytes):0Averageresidentsetsize(kbytes):0Major(requiringI/O)pagefaults:0Minor(reclaimingaframe)pagefaults:264Voluntarycontextswitches:1Involuntarycontextswitches:1Swaps:0Filesysteminputs:0Filesystemoutputs:0Socketmessagessent:0Socketmessagesreceived:0Signalsdelivered:0Pagesize(bytes):4096Exitstatus:0Pagesize(bytes):40966.2MajorandMinorPageFaults(主要页错误和次要页错误)Linux,类似多数的UNIX系统,使用一个虚拟内存层来映射硬件地址空间.当一个进程被启动,内核先扫描CPUcaches和物理内存.如果进程需要的数据在这2个地方都没找到,就需要从磁盘上读取,此时内核过程就是majorpagefault(MPF).MPF要求磁盘子系统检索页并缓存进RAM.一旦内存页被映射进内存的buffercache(buff)中,内核将尝试从内存中读取或写入,此时内核过程就是minorpagefault(MnPF).与在磁盘上操作相比,MnPF通过反复使用内存中的内存页就大大的缩短了内核时间.以下的例子,使用time命令验证了,当进程启动后,MPF和 MnPF的变化情况.第一次运行进程,MPF会更多:#/usr/bin/timevevolutionMajor(requiringI/O)pagefaults:163Minor(reclaimingaframe)pagefaults:5918第二次再运行时,内核已经不需要进行MPF了,因为进程所需的数据已经在内存中:#/usr/bin/timevevolutionMajor(requiringI/O)pagefaults:0Minor(reclaimingaframe)pagefaults:55816.3TheFileBufferCache(文件缓存区)文件缓存区就是指,内核将MPF过程最小化,MnPF过程最大化.随着系统不断的产生I/O,buffercache也将不断的增加.直到内存不够,以及系统需要释放老的内存页去给其他用户进程使用时,系统就会丢弃这些内存页.结果是,很多SA(系统管理员)对系统中过少的freememory(空闲内存)表示担心,实际上这是系统更高效的在使用caches.以下例子,是查看/proc/meminfo文件:#cat/proc/meminfoMemTotal:2075672kBMemFree:52528kBBuffers:24596kBCached:1766844kB可以看出,这个系统总计有2GB(Memtotal)的可用内存.当前的空闲内存为52MB(MemFree),有24MB内存被分配磁盘写操作(Buffers),还有1.7GB页用于读磁盘(Cached).内核这样是通过MnPF机制,而不代表所有的页都是来自磁盘.通过以上部分,我们不可能确认系统是否处于瓶颈中.6.4TypeofMemoryPages在Linux内核中,memorypages有3种,分别是:1,ReadPages这些页通过MPF从磁盘中读入,而且是只读.这些页存在于BufferCache中以及包括不能够修改的静态文件,二进制文件,还有库文件