物理机CPU使用率报警

Posted 2023-03-29 码海拾贝2023

背景知识 (background)

CPU是稀缺的共享资源，CPU使用率过高，可能造成更多的上下文切换、调度延迟、CGroup CPU Throttle。

无论是物理机或容器化混合部署的应用，CPU做不到完全隔离，最多只能限制使用上限。部分进程CPU使用过多，会导致其他进程长尾请求增多。

虽然可限制进程只使用那几个CPU，但是出于资源利用率和运维复杂度考虑，很少启用。

CPU使用率的取值范围是 [0 , 1]，最大100%，调用JMX OperatingSystemMXBean的隐藏方法getSystemCpuLoad获取，计算逻辑是：user + nice / total ticks

查看指标 (dashboard)

其中，CPU Usage - 宿主机即物理机的CPU使用率 ，CPU Usage - 进程为JVM进程的CPU使用率。

另外， 系统负载里，可以看到物理机的CPU核数、进程最大可用的CPU核数。

止损措施 (action)

关注 FAST / 7层的499、监控狗的慢请求报警，若受到影响，可临时摘流节点。

事后改进(postmortem)

物理机CPU使用率考察的是整个系统CPU的饱和度，一般OP更关注，开发需评估对自身的影响。

对混部应用来说，若受到其他应用影响，可考虑调整节点流量权重 或者 联系OP迁移机器。

若是自身导致的（进程CPU使用率偏高），尽可能优化代码，降低单个请求的资源消耗 ，甚至调小进程的可用CPU。

可能的原因 (cause)

物理机CPU使用率是整台物理机所有混部应用的全局CPU使用率，可能是某个进程性能缺陷导致CPU使用过多或多个应用的流量高峰期重叠导致CPU紧张。

触发的原因( cause )非常之多，我们列了部分原因 ，可针对性优化。

一、定时任务、计算逻辑过多

我们建议定时任务尽可能在凌晨的流量低峰期执行，避免白天的流量高峰期。

若无法避免高峰时段执行，可尝试任务分片、隔离部署，比如，薪酬月初算薪，进程CPU使用率达到40%，k8s容器部署的话，月初可临时调度薪酬进程到独享的物理机，和其他应用隔离，算薪完成了再调度回去，释放资源。

另一种情况是，业务加载大批量数据、在内存里聚合计算的场景，建议分批加载、预计算，避免内存和CPU占用过多。

二、机器配置差

生产环境不同物理机的CPU数不尽相同，通常在 16、20 、24、32 、40、48等。

物理机的CPU个数可展开进程 / 线程 / CPU / 磁盘 / IO这一行的宿主机 System Load。

低配置的物理机，流量大的情况下，CPU波动大。 如果应用比较重要的话，可考虑迁移到其他机器。

三、 混部应用流量高峰期重合

流量高峰期重合是不可避免的，比如早高峰8:30-11点，但是若多个大流量应用部署到同一个物理机上，CPU竞争的概率就更大了。

建议迁移部分应用到其他机器，避免流量集中，甚至上下游在同一个机器上。

四、混部应用CPU没限制或配额大，使用率过高

SRE托管的应用开启了CGroup CPU限制，但是部分早期部署的应用，CPU无限制或限额过高，比如，40CPU的物理机，有的应用可允许使用16CPU，如果此应用的代码有性能缺陷，会消耗过多CPU，达不到资源隔离的目的。

运维始终在平衡资源使用率和稳定性，我们建议将业务进行分级：基础服务(一级业务）、核心业务(二级业务）、普通应用(三级业务)，不同级别、不同语言的应用对CPU的要求不同。

对Python / NodeJs / php / GO 等多进程应用，可严格限制CPU额度；对JVM等多线程应用来说，CPU应适当调大点，多CPU意味着更大的线程并行度。

开启了CGroup CPU限制的应用，所有基于CPU的配置须以CPU额度为基准，通常不识别CGroup的语言以物理机的CPU个数为基准，可能需要手动调优，比如，GC线程数、EventLoop个数、ForkJoin并行数。

以JVM应用为例，推荐配置：

业务级别

CPU额度

注意事项

基础服务(一级业务)

12CPU

GC线程、NIO/Netty等EventLoop的个数以CPU额度为基准

核心业务(二级业务）

8CPU

GC线程、NIO/Netty等EventLoop的个数以CPU额度为基准

普通业务(三级业务)

4CPU

GC线程、NIO/Netty等EventLoop的个数以CPU额度为基准

CPU通常是瓶颈，内存不是，为提升物理机资源使用率，可采取以下方式差异化部署：

1. 70%的普通业务 + 30%少量核心业务，所有应用严格限制CPU额度，随流量扩容。
2. 少量基础服务 + 少量的普通业务，基础服务通常不会那么多，为保证可用性，可牺牲一定的资源使用率。

总之， CPU消耗少的，可以密集部署，提升单机部署应用的个数，合理利用内存；对CPU敏感的应用，可控制部署数量，尽量分散开。