CPU 利用率异常的分析思路和方法 （来自社区会员交流活动，社区专家杨建旭总结梳理成文）
常见CPU问题总结就是这几类：
1、CPU使用率过高
2、CPU使用率太低
3、CPU使用率各核使用不均衡
分析的基础是监控，监控项可参考：性能测试监控——CPU
在生产运行当中，经常会遇到CPU利用率异常或者不符合预期的情况，下面这些知识可以帮助你。
1
基本概念类问题
(一) CPU的占用是怎么产生的？为什么不同OS下的CPU利用率不同？
操作系统是用来调度任务（进程）和管理外围设备的系统，操作系统采用自己的进程调度策略将进程调度到CPU上运行，占用了CPU时间片，由此产生了CPU的占用。
为什么不同OS下的CPU利用率不同呢？有以下几方面的原因：
1. 不同的操作系统管理外围设备的方法、进程调度的算法、内存管理的算法等等有差异，因此同一个应用在不同的OS下的CPU消耗可能不一样。
2. 同一个应用安装在不同的设备上（包括硬件+OS+系统软件），并不能保证参数都是一样的。即使是同一个版本的OS，由于应用和OS的参数配置太多，可能某个参数配的不一样，相差很大的CPU利用率都是可能的。举几个例子：
- 一个采用文件系统，另一个采用裸设备
- 一个设置了CPU折叠，一个没设置
- 一个写磁盘是按照4K写入，另一个按照64K写入，那么diskbusy的百分比相差很大，CPU的繁忙程度也略有不同
3. 不同OS上，CPU数读工具的统计方法可能不一样，即使是同一个OS，不同的CPU读数工具的统计方法也可能不一样。
有人提到，“Linux on Power的处理器利用率比AIX的处理器利用率相比少得多”，这个现象并不奇怪。即使都是AIX，同一个应用在AIX61上和AIX71上，CPU利用率也不同，我做过实验，AIX71相比AIX61做了一定的优化。
(二) 为什么多核CPU的利用率分布不均匀
问题：在AIX系统，利用topas查看时，发现只有一个CPU的利用率很高，其他的core利用率几乎为零，怎么可以调整参数，使得其他的core的利用率增大？在Linux下的问题同样的疑问。
从应用角度，很可能应用是个单进程，不能分到多个CPU上运行。如果已经是个多进程应用，那就可能并发数设置为1了，需调大并发数后才能分配到多个核运行。
从操作系统层面，系统会把进程调度到上一次使用的CPU，以避免进程的上下文切换。一个CPU干的好好的，当然不会调到其他CPU，不然上下文切换代价大。因此，如果压力不是很大的时候，当然是只有一个core的利用率较大，而其他core是闲置状态。
(三) CPU利用率的正常使用范围是多少？
一般来说，生产运行环境中CPU 70%会报警。有些谨慎、保守的单位，CPU超过40%就着手扩容了。
但并不是说CPU一超过70%就一定是异常，对于夜间的批处理业务，可能更多的是期望它尽多占用CPU、尽快处理完成，以免影响第二天的开门。
(四) CPU利用率当中的Sys%高是什么原因？
如果系统态占比比较大，一般有以下几类原因：
1. 为了追求效率，减少用户态到系统态的转换，把用户态的function改到系统态，例如：一些驱动程序，以显卡驱动最为常见
2. 系统有IO问题
3. 应用设计问题
例1：频繁调用sync函数做缓存到磁盘的数据同步，就会产生大量sys%，并且这个sys%中，大量的是kernel态的wait和sync。
例2：反复load/unload so文件。
例3：阻塞方式的网络收发
2
问题诊断思路
(一) CPU利用率上不去
CPU有两头怕
1）怕CPU占用率高
2）怕CPU占用率低
重点解释一下为什么怕CPU低。有时候，业务压力冲上来了，但都被挡在外面，或者堆在队列了，而此时看CPU利用率却很低，也就是有CPU但没有用上。
这种情况有好多原因，这里说几个原因：
1）并发线程数太少
并发数应该开多少呢？ 假如你的应用线程是全力干活的线程，没有什么SLEEP、等IO之类的事情，也就是说，一个线程可以把一个物理CPU THREAD吃的满满的。那么你的最大并发线程，可以设为略小于服务器的逻辑CPU数量。也就是CPU CORE* SMT。如果你是虚拟化POWERVM环境，逻辑CPU=VPSMT，但虚拟化环境，需要额外注意，如果你要保持高性能，那么建议略小于ECSMT即可。
2）虚拟化平台的参数配置有问题
比如某个LPAR，EC=0.5，VP=5，那么很可能，压力来了之后，CPU利用率也上不去，报文严重堆积。因为可能系统环境中物理机的CPU占用率已经较高，各个LPAR之间借用CPU已经非常严重，大部分时间都花在hypervisor的调度上，以及CPU的cache命中失败去内存找数据取了。
关于这方面的原理，可以参看
3）其他各类参数限制导致应用能力被约束，尤其以数据库为甚
比如应用连接Oracle数据库服务器的JDBC连接数太少，数据库的process太少等等，导致应用在等待数据库。如果单从数据库来讲，以Oracle为例，可以看看AWR的top等待事件。
比如logswitch等待时间长，可能需要调整redo日志组数和日志大小
比如索引等待时间长，可能需要调整为索引分区
比如rego日志sync等待时间长，可能需要调整存储的能力。
4）应用逻辑设计问题
逻辑设计复杂，流转过程长，导致不能很好的并发利用资源。
可以类比CPU流水原理，CPU设计为什么设置多级流水，而不是一级流水把一个指令执行完。
(二) CPU利用率居高不下
主机资源使用繁忙，到底是因应用需要做优化处理还是确实物理资源不足导致？
1. CPU资源不足，首先可以考虑优化。优化首先考虑技术层面优化
2. 如果技术优化无果，则进入业务优化。更改业务流程，业务处理方式。例如：
a) 实时检查，改为定期检查
b) 每秒钟检查一次，改为每分钟检查一次
c) 实时清算改为定时清算
3. 如果业务优化仍然无果，则需要加资源，甚至从总体上更改架构。毕竟任何CPU、任何服务器、任何系统都是有业务上限的。
CPU利用率居高不下的原因：
1. 绝大多数情况是应用写的烂
算法差，或者无意的应用调用，触发了内核函数占用CPU高。
这里所说的应用包括中间件、数据库（比如SQL写的差，没做变量绑定（硬解析），索引设置不合理，数据库物理设计不合理等等）。
2. 参数类 系统参数（比如缓存什么情况下往硬盘刷，设置不得当，刷的频率太快） 编译参数（各种优化选项，以及各种依赖关系） 数据库参数（比如可以共享游标去节省CPU消耗，但却没有做） 中间件参数（比如GC策略）
AIX 关键业务系统CPU使用率高居不下，但是未对业务系统造成影响，如何进一步具体分析？
如果在贵单位认定的标准线以内，比如，CPU%不超过70即认为可以接受，不处理也没关系。
1）有些应用可能已经优化到极致了。接下来考虑的是扩容、容量规划，必要时调整架构（分布式，大数据）。容量规划可以采用以下的步骤：
收集性能,、容量和事件数据（服务器统计数据，网络统计数据，存储统计数据，业务统计数据）
分析服务器性能和业务需求
性能趋势分析，判断未来需求
关联数据，对性能和容量进行深入分析
提供“what-if”分析，识别未知的瓶颈
考虑虚拟化技术、优化成本、 供应和需求
生成报表提供更好的决策支持
2）如果不考虑扩容，仅考虑优化
采用nmon、topas、tprof，curt等工具分析什么进程、线程、函数占用了CPU，或者CPU在等待什么事件，进行深入分解和分析
(三) 如何应对CPU使用率毛刺问题？
毛刺不可怕，OS的CPU调度也不一定那么完美
首先需要判断毛刺是1）周期性的，或者2）杂乱无章的，或者3）偶尔的突起。
1. 周期性的毛刺
列举几种可能的原因：
第一：发送到该服务器的业务量本身有周期性的增大。
第二：某个进程/任务周期性占用。如果是周期性监控进程占用CPU，问问监控系统的开发人员，咨询监控软件时候时间点发起监控、内部发起了什么操作或命令，这些操作是否可以优化。
第三：定期的锁导致业务量在锁时期积压，锁释放后冲高
2. 杂乱无章的毛刺
第一：发送到该服务器的吞吐量本身有是高低不一的。
第二：读取队列的算法有问题，读取不均匀
第三： OS调度问题
3. 偶发的毛刺
可以采用脚本或代码抓取当CPU出现毛刺时的调用栈（CoreDump、tprof、truss等）。
也很有可能是某应用程序、系统程序或操作系统的bug
(四) 偶尔异常
有没有好的方法监控异常占用CPU的进程？
这里采用的方法和“CPU偶发的毛刺”采用的方法一样，采用脚本或代码抓取当CPU出现毛刺时的进程和调用栈（nmon、ps、CoreDump、tprof、truss等方法）。
3
诊断工具
(一) CPU分析
vmstat, iostat, ps, sar, gprof/prof/tprof,time/timex, netpmon, locktrace,emstat,alstat,topas,trace, trcrpt,curt,splat,truss,procstack 等
(二) CPU优化
procmon,larstat,mpstat,cpupstat,nice/renice,schedo,bindprocessor,chdev,setpri等
(三) 实例
可以参考社区“系统性能测试”专栏中的几篇文章（http://www.aixchina.net/Column/detail/id/9）
性能指标之资源指标-CPU-谁占用了CPU-进程级
性能指标之资源指标-CPU-谁占用了CPU-函数级-tProf
性能指标之资源指标-CPU-谁占用了CPU-函数级-curt
性能指标之资源指标-CPU-谁占用了CPU-函数级-truss
性能指标之资源指标-CPU-谁占用了CPU-函数级-CoreDump
(四) 收集CPU信息数据时需要注意一些什么？
需避免对业务运行造成影响。收集数据越全面的工具，消耗越多的资源（CPU、磁盘IO、存储空间）。最好在业务量低的时候收集，除非你的问题是在业务量高的时候才出现。
收集时间要短，如果1分钟的数据够用，就只搜集1分钟。像trace这样的收集工具是每个逻辑CPU都分别搜集，如果你的几十个CPU上跑的进程都差不多，可以少搜集一些CPU。
4
虚拟化相关
(一) PowerVM环境下的CPU监控和分析与物理机环境有哪些差异？
首先：利用率的概念不同。
虚拟化环境下CPU利用率相对于EC（标称计算能力）来说，可以超过100%。
相对于VP（虚拟CPU）来说，永远是<=100%。
相对于运行时获得的物理CPU来说，永远是<=100%。
CPU利用率的统计方法：
第二：虚拟化环境关注的参数更多，这些参数会对性能产生巨大的影响
虚拟化环境需同时关注以下参数：
CPU核数
标称计算能力（Entitled Capacity，简称EC）
虚拟CPU（Virtual CPU，简称VP）
逻辑CPU个数（Logical CPU）
SMT
有上限/无上限（Capped/Uncapped）
型号/时钟频率
处理器折叠（Processor Folding）
运行时物理CPU（Physical CPU）
可以参考：
(二) 开发的应用在CPU核数一样的虚拟服务器上性能表现出较大的差异
1、用的是什么虚拟服务器？VMware还是PowerVM的？还是其他的平台？
2、假如是VMware，用的是ESX/vSphere还是VMware Workstation，二者架构不同，性能不同，PC上的VMware Workstation不是裸金属模式，性能不好。
3、虚拟机上看到的核数，可能不是真正的核数。比如说VMware上，看到的2个core，其实是x86 CPU的一个core中的一个超线程。
如果这个x86 CPU一个core是两个线程，那么虚拟机中的两个core只相当于物理的一个core。当然，这是能够完全抢占的情况下。如果没有完全抢占，那就更小了。
如果是PowerVM的虚拟机，操作系统看到的核数是VP（虚拟CPU），至于这个LPAR运行时候，能得到多少物理CPU以及这些物理CPU的亲和性，可能差异很大。
PowerVM上CPU的概念可以参考：
性能指标之资源指标 CPU配置参数对性能的影响
(三) 虚拟化下CPU核数超分配有没有最佳实践
问题：在虚拟化的环境下，一般可以超分配CPU核数。一般会有一个临界值。过了这个值CPU性能就大幅下滑。我们如何找这个值，有没有什么最佳实践？
所谓的“最佳实践”其实是厂商给出通用值，具体到你的单位头上，并不一定是最佳的。世界上没有所谓的通用的最佳。就好比，两地三中心、异地双活之类的设计方案，没有什么最佳实践，每个企业都有根据自己的特点来设计。
回到你的问题，如果你的系统追求最短的响应时间（核心交易系统），VP和EC的比值越小越好。如果，追求最大瞬时CPU获得，设置大一些更好，最大可以是10，适用于平时没有什么业务量的非核心系统。
(四) EC高低似乎对业务响应时间没什么影响，为什么？
问题1：
解答1：
这个是需要运气的。
是否做上下文切换，取决于进程是不是每次被调用到同一个VP上，VP是不是每次被调用到同一个物理CPU上。
如果你的资源池，资源比较充足，那么hypervisor按照亲和性调度，你的VP每次得到的物理CPU是一样的，所以响应时间不受影响
反之，资源紧张，多个LPAR争抢，亲和性大打折扣，响应时间就起伏很大。
亲和性的数值，可以通过下面方式查询
Nmon的BBBP sheet
命令行Mpstat –d
问题2：
"那么如果要看运气的话，物理资源多少才算闲置，总利用率多少需要开始关注CPU亲和度了，需要开始着手处理此类问题了"
解答2：
首先要理解亲和度的概念，是CPU是否能从cache1、2、3里面读到数据。举个例子，有1000个进程跑在一个CPU上，但都是不怎么干活的进程，一会儿进程A上来占用，一会进程B上来占用，但总体CPU利用率并不高，但每个进程上来后都要有自己的进程上下文。可能此时cache1、2、3根本缓存不了这么多上下文。结果就是大量的上下文切换。
因此不会有一个绝对的指标，说物理资源多少才开始关注CPU亲和度。
针对 “物理机的整体CPU利用率究竟达到多少时，需要考虑扩大LPAR的EC”
是否扩大LPAR的EC，主要考虑的是你的业务需求是否能够得到满足（例如，响应时间是否满足要求，吞吐量是否跟得上），而不是主要考虑物理机的整体CPU利用率。
CPU各核之间负载不均衡
1、nginx、redis之类的软中断引起的负载不均衡，通过设置CPU亲和性来调整 记录一个多核CPU负载不均衡问题
2、进程多个核上负载不均衡，进程在多核CPU环境下分布不均导致TCP连接堆积
