CPU利用率异常分析讨论会-问题诊断思路

(一) CPU利用率上不去

CPU有两头怕

1）怕CPU占用率高

2）怕CPU占用率低

重点解释一下为什么怕CPU低。有时候，业务压力冲上来了，但都被挡在外面，或者堆在队列了，而此时看CPU利用率却很低，也就是有CPU但没有用上。

 

这种情况有好多原因，这里说几个原因

1）并发线程数太少

并发数应该开多少呢？ 假如你的应用线程是全力干活的线程，没有什么SLEEP、等IO之类的事情，也就是说，一个线程可以把一个物理CPU THREAD吃的满满的。那么你的最大并发线程，可以设为略小于服务器的逻辑CPU数量。也就是CPU CORE* SMT。如果你是虚拟化POWERVM环境，逻辑CPU=VP*SMT，但虚拟化环境，需要额外注意，如果你要保持高性能，那么建议略小于EC*SMT即可。

2）虚拟化平台的参数配置有问题

比如某个LPAR，EC=0.5，VP=5，那么很可能，压力来了之后，CPU利用率也上不去，报文严重堆积。因为可能系统环境中物理机的CPU占用率已经较高，各个LPAR之间借用CPU已经非常严重，大部分时间都花在hypervisor的调度上，以及CPU的cache命中失败去内存找数据取了。

关于这方面的原理，在我之前的文章中有提到

PowerVM虚拟化下的核心交易系统性能保持

性能指标之资源指标 CPU亲和性原理介绍及如何量化读数

3）其他各类参数限制导致应用能力被约束，尤其以数据库为甚

比如应用连接Oracle数据库服务器的JDBC连接数太少，数据库的process太少等等，导致应用在等待数据库。如果单从数据库来讲，以Oracle为例，可以看看AWR的top等待事件。

比如logswitch等待时间长，可能需要调整redo日志组数和日志大小

比如索引等待时间长，可能需要调整为索引分区

比如rego日志sync等待时间长，可能需要调整存储的能力。

4）应用逻辑设计问题

逻辑设计复杂，流转过程长，导致不能很好的并发利用资源。

可以类比CPU流水原理，CPU设计为什么设置多级流水，而不是一级流水把一个指令执行完。

(二) CPU利用率居高不下

1）主机资源使用繁忙，到底是因应用需要做优化处理还是确实物理资源不足导致？

1. CPU资源不足，首先可以考虑优化。优化首先考虑技术层面优化

2. 如果技术优化无果，则进入业务优化。更改业务流程，业务处理方式。例如：

    a)      实时检查，改为定期检查

    b)     每秒钟检查一次，改为每分钟检查一次

    c)      实时清算改为定时清算

3. 如果业务优化仍然无果，则需要加资源，甚至从总体上更改架构。毕竟任何CPU、任何服务器、任何系统都是有业务上限的。

 

2）CPU利用率居高不下的原因

1. 绝大多数情况是应用写的烂

算法差，或者无意的应用调用，触发了内核函数占用CPU高。

这里所说的应用包括中间件、数据库（比如SQL写的差，没做变量绑定（硬解析），索引设置不合理，数据库物理设计不合理等等）。

2. 参数类

系统参数（比如缓存什么情况下往硬盘刷，设置不得当，刷的频率太快）

编译参数（各种优化选项，以及各种依赖关系）

数据库参数（比如可以共享游标去节省CPU消耗，但却没有做）

中间件参数（比如GC策略）

 

3）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等方法）。