NMON中的CPU利用率不一致原因分析

1、 NMON 中几处 CPU 利用率不一致原因分析 有时我们说到nmon、topas、ps等几个命令中显示的CPU利用率不一致，那可以归结为CPU利用率的算法不一致，其实也就是分母不一致导致（除以不同数量的CPU）。但很多同学在看nmon中的CPU利用率的时候都表示困惑，同是一份nmon报告，好几处出现CPU利用率的地方，为什么也不一致。由于从来就没有什么文档来介绍这些数据之间的关联，本文就来解释这些问题。CPU_ALL和TOP页不一致首先我们看CPU_ALL这个Sheet，CPU利用率大概是75%的样子有时候想知道是哪些进程占了CPU，我们就切换到TOP这个Sheet。问题来了，占用CPU最高

2、的进程是cicsas，平均利用率（WAvg）是17%。而其他进程最大也就2%的平均利用率，而且这样的进程只有5个。那么总CPU利用率75%是怎么凑出来？Avg和WAvg的区别说这个问题之前，我们先解释一下进程CPU利用率中Avg、WAvg的含义和区别。Avg是这段时间内利用率的平均值。WAvg，这个是重点，WAvg是除去0值之后的平均值。所以WAvg一定是大于等于Avg的。绝大多数情况下，我们看是WAvg而不是Avg。因为我们统计的是进程运行时候的占用情况，图1就是一个例子。中间有不运行的时间段，统计avg是没有意义的。CPU_ALL和TOP的统一言归正传，总CPU利用率75%是怎么凑出来？我

3、们还得从头说起。TOP Sheet中按照command筛选，把那个CPU最高的进程（cicsas）选出来。我们看到15:30:52这个时间点有20个cicsas进程，可以用肉眼数出来，也可以看Threads这个列的数据。当然肉眼数的结果和Threads列显示的结果不一定一致。因为肉眼看到的是CPU利用率排到top的进程，没有进入top行列是不会显示出来的。本次nmon的监控是30秒一次，这20个进程是同一个时间点（15:30:52）监控出来的，而不是从15:30:52到15:31:12这30秒内陆陆续续监控出来的。也就是说，当前系统cicsas进程的并发数是20。这20个cicsas进程每个进

4、程都有24%左右的CPU利用率，它们加起来有240%，这是什么鬼？明显超过了100%，那么说明每个进程的CPU利用率都是针对单个CPU的利用率，而不是针对系统所有CPU的利用率。也就是说CPU利用率的计算公式中，分母是1。假如系统中有个10个CPU，有1个进程P，P占用了一整颗CPU，利用率为100%，不考虑其他进程，我们看整机的CPU_ALL中的利用率就是10%。其实在解释Avg的时候并没有解释清楚，我们继续解释。avg这个利用率指的是相同进程名的所有进程的平均值，另外还有一个时间维度，不同时间点的平均值再进行一次平均，就得到了Avg这个值。如果除去0值做平均，得到是WAvg这个值。所以，在

5、这个CPU的TOP的图上，有时候我们看到柱子高的进程占用CPU不一定最多，因为还需要把进程的数量考虑在内。在图2中，WAvg是17.5%左右，由于有20个进程，它们总的CPU占用是17.5%*20=350%。而这个值是相对于单颗CPU的利用率，我们只要除以CPU总数应该就可以和CPU_ALL中的75%对应上了。此时似乎疑团散去，但问题还在后面。好了，我们来看看这个LPAR的CPU配置，来到BBBL Sheet8颗虚拟处理器，2个EC。刚才计算的350%，除以8=43.75%，除以2=175%，和我们的目标75%明显不着边。这。难道我们分析错了吗？为了解释清楚这件事，我们需要从CPU_ALL的算

6、法开始说。由于大家大脑中的CPU利用率最多是100%，不能再多了。而虚拟化之后，有超过标称计算能力（EC）一说，比如分配了2个core的能力（EC=2），而运行当中，由于2个core的能力不够，LPAR抢占了3个core的能力，这时候CPU利用率按理说就是150%了。事实上，topas这个命令有个Entc这个指标，大致就是这个意思。如果Entc超过100%，就说明当前占用的物理CPU的数量已经超过了预设的EC。但NMON的设计者担心具有传统思维的遗老遗少接受不了150%这个现实，就把CPU利用率强行控制在100%以内。方法嘛就是增大分母，分母是多少呢？从LPAR Sheet看出，运行时获得的物

7、理CPU的数量（蓝色线）是动态的，而且大部分时候是超过2C的，右侧有压力的时间段，平均值大概是5。我们的350%除以5=70%。这就和75%基本对上了。75%和70%之间的5%是cicsas这个超级CPU饭桶之外的那些小进程的消耗。CPU_ALL和LPAR页的统一需要说明的是，CPU_ALL算法里面分母是动态的，因为运行时获得物理CPU数量是动态的。但并不是所有时候分母都是动态的。当Physical CPUEC时，CPU利用率=（用户态CPU+系统态CPU）/运行时物理CPU，也就是物理CPU利用率。当Physical CPU=EC时，CPU利用率=（用户态CPU+系统态CPU）/EC值。通过

8、这样的算法，当Physical CPU很小，约等于0的时候，可以看到CPU利用率也基本=0，而不会出现本来没用CPU但CPU利用率很高的误导图形但不管怎么说，这个CPU_ALL还是比较误导人。你分母是变的，我统计CPU利用率到底是多少颗CPU的利用率呢？这里我们可以引入一个VP利用率的指标。这个指标的好处是分母是固定的，分母就是VP的数量VP利用率=（用户态CPU+系统态CPU）/VP值图中的例子，看16:11:13这个时间点EC利用率=135.54%+53.01%=188.55%，EC=2，就是说按照2颗CPU来说，当前LPAR占用了2*188.55%=3.771颗CPUVP利用率=33.8

9、8%+13.25%=47.13，VP=8，按照8颗CPU来说，当前LPAR占用了8*47.13%=3.7704颗CPU而CPU_ALL中的CPU利用率=3.77/5.076=74.3%我们跳转到CPU_ALL Sheet看看16:11:13，CPU%果然是74.3%。所以，对于这种physical CPU超过EC，飘忽不定的分母，是不能用CPU_ALL中的数值的，而应该用LPAR中的VP利用率=（用户态CPU+系统态CPU）/VP值。出具统计结果的时候，可以说“在8颗CPU的时候，CPU利用率是xxx%”。作者：杨建旭。现任中国人民银行清算总中心性能测试团队负责人，高级技术经理。社区个人专栏系

10、统性能测试地址：/Column/detail/id/9扩展阅读nmon命令显示与使用analyzer分析后数据不一致的问题（问题来自社区会员hashei）最近在分析一个java内存的问题，发现使用nmon命令查看进程内存占用情况和采集数据用nmon analyzer进行分析数据上会有差异。nmon m 4 结果如下：可以看到PID 1704276的Res Set为1534612k，物理内存为30G，所以RAM USE 1.5/30=0.05是准确的。但nmon数据用analyzer分析后对应的数据如下：%RAM为22.6%，这个数值是如何得出的，是由于nmon版本和分析工具版本的问题导致的？另

11、外这个java进程的启动参数为-Xms8g -Xmx8g -XX:PermSize=512m，先不考虑non-heapsize部分，heapsize部分的8G在启动后不应该运行在内存中吗，为什么RSS看到的仅为1.53G呢？难道nmon的res set并不是RSS？问题解答（来自社区专家杨建旭）：首先，连名字都不一样，那么含义一定不一样。第二，在aix上，不同命令显示中的 相同的词（比如size），含义也不一样。因为这些工具都是分别开发的。第三，nmon命令中 Res SizeThe sum of real-memory data (resident set) and real-memory (resident set) text size of the process.进程数据段和代码段在物理内存中