linux top命令中各cpu占用率含义
linuxtop命令中各cpu占用率含义
0.3%us用户空间占用CPU百分比
1.0%sy内核空间占用CPU百分比
0.0%ni用户进程空间内改变过优先级的进程占用CPU百分比
98.7%id空闲CPU百分比
0.0%wa等待输入输出的CPU时间百分比
0.0%hi硬中断
0.0%si软中断
======================================================
LinuxSystemandPerformanceMonitoring(CPU篇)
博客分类：性能测试
linuxperformance
LinuxSystemandPerformanceMonitoring(CPU篇)
Date:2009.07.21
Author:DarrenHoch
译:Tonnyom[AT]hotmail.com2009.08.10
前言:网上其实有很多关于这方面的文章,那为什么还会有此篇呢,有这么几个原因,是我翻译的动力,第一,概念和内容虽然老套,但都讲得很透彻,而且还很全面.第二,理论结合实际,其中案例分析都不错.第三,不花哨,采用的工具及命令都是最基本的,有助于实际操作.但本人才疏学浅,译文大多数都是立足于自己对原文的理解,大家也可以自己去OSCAN上找原文,如果有什么较大出入,还望留言回复,甚是感激!
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个系统性能的基准线快照,用来比较当高负荷时的系统性能快照.
#vmstat1
procsmemoryswapiosystemcpu
rbswpdfreebuffcachesisobiboincsussywaid
1013859217932126272214244001181091921196
001385921793212627221424400001054601099
00138592179321262722142440000198624014045
0013859217932126272214244000011749000100
0013859217924126272214244000176220938341380
001385921792412627221424400003581522817075
101385921792412627221424400003681447424072
001385921792412627221424400003521277912079
#vmstat1
procsmemoryswapiosystemcpu
rbswpdfreebuffcachesisobiboincsussywaid
2014594017752118600215592011181091921196
2014594015856118604215652000468789108861400
3014620813884118600214640036003604987191900
20146388137641186002137880340034067241871300
20147092137881186002124520740013246206192800
2014736013848118600211580072007206904196400
2014791213744118192210592072007206054495500
20148452139001181922092600372037263945811900
20149132136921178242084120372037245747901000
从上面第一个结果可看到,最后一列(id)表示的是空闲时间,我们可以看到,在基准线统计时,CPU的空闲时间在79%-100%.在第二个结果可看到,系统处于100%的占用率以及没有空闲时间.从这个比较中,我们就可以确定是否是CPU使用率应该被优化.
2.0安装监控工具
多数*nix系统都有一堆标准的监控命令.这些命令从一开始就是*nix的一部分.Linux则通过基本安装包以及额外包提供了其他监控工具,这些安装包多数都存在各个Linux发布版本中.尽管还有其他更多的开源以及第三方监控软件,但本文档只讨论基于Linux发布版本的监控工具.
本章将讨论哪些工具怎样来监控系统性能.
ToolDescriptionBaseRepository
vmstatallpurposeperformancetoolyesyes
mpstatprovidesstatisticsperCPUnoyes
sarallpurposeperformancemonitoringtoolnoyes
iostatprovidesdiskstatisticsnoyes
netstatprovidesnetworkstatisticsyesyes
dstatmonitoringstatisticsaggregatornoinmostdistributions
iptraftrafficmonitoringdashboardnoyes
netperfNetworkbandwidthtoolnoInsomedistributions
ethtoolreportsonEthernetinterfaceconfigurationyesyes
iperfNetworkbandwidthtoolnoyes
tcptracePacketanalysistoolnoyes
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-每个处理器应该运行队列不超过1-3个线程.例子,一个双核处理器应该运行队列不要超过6个线程.
CPUUtiliation-如果一个CPU被充分使用,利用率分类之间均衡的比例应该是
65%-70%UserTime
30%-35%SystemTime
0%-5%IdleTime
ContextSwitches-上下文切换的数目直接关系到CPU的使用率,如果CPU利用率保持在上述均衡状态时,大量的上下文切换是正常的.
很多Linux上的工具可以得到这些状态值,首先就是vmstat和top这2个工具.
4.1vmstat工具的使用
vmstat工具提供了一种低开销的系统性能观察方式.因为vmstat本身就是低开销工具,在非常高负荷的服务器上,你需要查看并监控系统的健康情况,在控制窗口还是能够使用vmstat输出结果.这个工具运行在2种模式下:average和sample模式.sample模式通过指定间隔时间测量状态值.这个模式对于理解在持续负荷下的性能表现,很有帮助.下面就是
vmstat运行1秒间隔的示例:
#vmstat1
procs-----------memory-------------swap-------io------system------cpu----
rbswpdfreebuffcachesisobiboincsussyidwa
001043001680095328722000052671441950
001043001680095328722000002410216411980
00104300168009532872200000010095911980
Table1:ThevmstatCPUstatistics
FieldDescription
rTheamountofthreadsintherunqueue.Thesearethreadsthatarerunnable,buttheCPUisnotavailabletoexecutethem.
当前运行队列中线程的数目.代表线程处于可运行状态,但CPU还未能执行.
bThisisthenumberofprocessesblockedandwaitingonIOrequeststofinish.
当前进程阻塞并等待IO请求完成的数目
inThisisthenumberofinterruptsbeingprocessed.
当前中断被处理的数目
csThisisthenumberofcontextswitchescurrentlyhappeningonthesystem.
当前kernelsystem中,发生上下文切换的数目
usThisisthepercentageofuserCPUutilization.
CPU利用率的百分比
sysThisisthepercentageofkernelandinterruptsutilization.
内核和中断利用率的百分比
waThisisthepercentageofidleprocessortimeduetothefactthatALLrunnablethreadsareblockedwaitingonIO.
所有可运行状态线程被阻塞在等待IO请求的百分比
idThisisthepercentageoftimethattheCPUiscompletelyidle.
CPU空闲时间的百分比
4.2案例学习:持续的CPU利用率
在这个例子中,这个系统被充分利用
#vmstat1
procsmemoryswapiosystemcpu
rbswpdfreebuffcachesisobiboincsussywaid
302065641509280336176080000071826811900
20206564147728033617612000007582396400
10206564142088033617613600008202096400
10206956138847918017596404120268010088093700
2020734814448788001755760412041276370841600
202073481575678800175424000087425891100
102073481636878800175596000094024861400
10207348166007880017560400009292795302
30207348169767854817587600025089693593700
40207348162167854817570400008743693601
402073481642478548175776000085026772300
202073481749678556175840000073623831700
00207348176807855617586800008612191801
根据观察值,我们可以得到以下结论:
1,有大量的中断(in)和较少的上下文切换(cs).这意味着一个单一的进程在产生对硬件设备的请求.
2,进一步显示某单个应用,usertime(us)经常在85%或者更多.考虑到较少的上下文切换,这个应用应该还在处理器中被处理.
3,运行队列还在可接受的性能范围内,其中有2个地方,是超出了允许限制.
4.3案例学习:超负荷调度
在这个例子中,内核调度中的上下文切换处于饱和
#vmstat1
procsmemoryswapiosystemcpu
rbswpdfreebuffcachesisobiboincsussywaid
212077409847681344180972002496090028834125727
012077409644883304180984001968328810255989830
0120774094404853481809840020440829287996787
01207740925768717618098400182806892088397810
2020774091300884521809840012760565218276834
3120774090124896281809840011760551221927910
422077408924090512180984008805204439072210670
532077408805691680180984001168062812481211770
4220774086852928801809840012000654150567870
61207740857369399618098400111605261512510850
012077408484494888180984008920438155664900
根据观察值,我们可以得到以下结论:
1,上下文切换数目高于中断数目,说明kernel中相当数量的时间都开销在上下文切换线程.
2,大量的上下文切换将导致CPU利用率分类不均衡.很明显实际上等待io请求的百分比(wa)非常高,以及usertime百分比非常低(us).
3,因为CPU都阻塞在IO请求上,所以运行队列里也有相当数目的可运行状态线程在等待执行.
4.4mpstat工具的使用
如果你的系统运行在多处理器芯片上,你可以使用mpstat命令来监控每个独立的芯片.Linux内核视双核处理器为2CPU's,因此一个双核处理器的双内核就报告有4CPU's可用.
mpstat命令给出的CPU利用率统计值大致和vmstat一致,但是mpstat可以给出基于单个处理器的统计值.
#mpstat–PALL1
Linux2.4.21-20.ELsmp(localhost.localdomain)05/23/2006
05:17:31PMCPU%user%nice%system%idleintr/s
05:17:32PMall0.000.003.1996.5313.27
05:17:32PM00.000.000.00100.000.00
05:17:32PM11.120.0012.7386.1513.27
05:17:32PM20.000.000.00100.000.00
05:17:32PM30.000.000.00100.000.00
4.5案例学习:未充分使用的处理量
在这个例子中,为4CPU核心可用.其中2个CPU主要处理进程运行(CPU0和1).第3个核心处理所有内核和其他系统功能(CPU3).第4个核心处于idle(CPU2).
使用top命令可以看到有3个进程差不多完全占用了整个CPU核心.
#top-d1
top-23:08:53up8:34,3users,loadaverage:0.91,0.37,0.13
Tasks:190total,4running,186sleeping,0stopped,0zombie
Cpu(s):75.2%us,0.2%sy,0.0%ni,24.5%id,0.0%wa,0.0%hi,0.0%
si
Mem:2074736ktotal,448684kused,1626052kfree,73756kbuffers
Swap:4192956ktotal,0kused,4192956kfree,259044kcached
PIDUSERPRNIVIRTRESSHRS%CPU%MEMTIME+COMMAND
15957nobody2502776280224R10020.50:25.48php
15959mysql2502256280224R10038.20:17.78mysqld
15960apache2502416280224R10015.70:11.20httpd
15901root16027801092800R10.10:01.59top
1root1601780660572S00.00:00.64init
#mpstat–PALL1
Linux2.4.21-20.ELsmp(localhost.localdomain)05/23/2006
05:17:31PMCPU%user%nice%system%idleintr/s
05:17:32PMall81.520.0018.4821.17130.58
05:17:32PM083.670.0017.350.00115.31
05:17:32PM180.610.0019.390.0013.27
05:17:32PM20.000.0016.3384.662.01
05:17:32PM379.590.0021.430.000.00
05:17:32PMCPU%user%nice%system%idleintr/s
05:17:33PMall85.860.0014.1425.00116.49
05:17:33PM088.660.0012.370.00116.49
05:17:33PM180.410.0019.590.000.00
05:17:33PM20.000.000.00100.000.00
05:17:33PM383.510.0016.490.000.00
05:17:33PMCPU%user%nice%system%idleintr/s
05:17:34PMall82.740.0017.2625.00115.31
05:17:34PM085.710.0013.270.00115.31
05:17:34PM178.570.0021.430.000.00
05:17:34PM20.000.000.00100.000.00
05:17:34PM392.860.009.180.000.00
05:17:34PMCPU%user%nice%system%idleintr/s
05:17:35PMall87.500.0012.5025.00115.31
05:17:35PM091.840.008.160.00114.29
05:17:35PM190.820.0010.200.001.02
05:17:35PM20.000.000.00100.000.00
05:17:35PM381.630.0015.310.000.00
你也可以使用ps命令通过查看PSR这列,检查哪个进程在占用了哪个CPU.
#while:;dops-eopid,ni,pri,pcpu,psr,comm|grep'mysqld';sleep1;
done
PIDNIPRI%CPUPSRCOMMAND
1577501586.03mysqld
PIDNIPRI%CPUPSRCOMMAND
1577501494.03mysqld
PIDNIPRI%CPUPSRCOMMAND
1577501496.63mysqld
PIDNIPRI%CPUPSRCOMMAND
1577501498.03mysqld
PIDNIPRI%CPUPSRCOMMAND
1577501498.83mysqld
PIDNIPRI%CPUPSRCOMMAND
1577501499.33mysqld
4.6结论
监控CPU性能由以下几个部分组成:
1,检查system的运行队列,以及确定不要超出每个处理器3个可运行状态线程的限制.
2,确定CPU利用率中user/system比例维持在70/30
3,当CPU开销更多的时间在systemmode,那就说明已经超负荷并且应该尝试重新调度优先级
4,当I/O处理得到增长,CPU范畴的应用处理将受到影响