进程CPU额度使用率报警

JavaProcessCpuQuotaUsageAlertV2

背景知识 (background)

无论是物理机或容器化部署的应用，通常使用CGroup进行资源隔离，开发可在应用大盘看到进程的CPU额度。

其中，CPU Quota是进程最大可用的CPU额度，若进程CPU使用率超过额度，会被操作系统限制CPU使用，慢请求会上升。

生产环境可能不同节点的内存/CPU额度不一样，可选择节点查看单台的准确额度。

进程 CPU Qutoa 使用率的取值范围是 [0 , 1]，最大100%，衡量的是单位时间内，进程可用的CPU额度已使用了多少，考察的是CPU够不够用，是否应该扩容了。

目前进程CPU额度的使用率超过了80%且持续1分钟，则会触发报警。

访问 kemonitor -> 应用 -> 监控狗 -> 节点监控，点开后，右上角可调整时间段。

展开: 进程 / 线程 / CPU / 磁盘 / IO这一行，找到监控面板：CPU Usage

其中，CPU Quota Usage - 进程即已分配给进程的CPU额度现在用了多少。

另外，开发也应关注监控面板: CGroup 统计[1m]里的近一分钟CPU Throttled占比，这个指标可侧面印证进程是否因CPU额度提前用尽而被限制了。

注意，因历史原因，不同节点的CPU额度可能不一样，另外，物理机的配置、性能也不尽相同。

关注 FAST / 7层的499、监控狗的慢请求报警，若报错、报警集中在单台，可临时摘流节点。

CPU额度不足，除了申请的套餐容量比较小之外，也可能是进程的CPU使用率过高(可参考: 进程CPU使用率的原因部分）。

容量套餐，基础服务建议在12CPU，核心应用8CPU，普通应用4CPU 。除此之外，可尝试扩容节点，降低单个节点的流量。

基础服务虽然可申请12CPU，但建议进程CPU使用率控制在10%以内，可适当冗余20%的节点数。

通常基础服务对性能、稳定性要求高，即在任何情况下，线程数、GC停顿、CPU使用率都尽可能稳定，避免毛刺。申请12CPU纯粹是为了避免OS限制CPU导致的长尾请求波动。

总之，CPU是极度稀缺的资源，内存相对比较充足，应用设计时，尽可能支持横向扩容、多部署一些节点，关注代码性能问题导致的单节点CPU消耗过多。

在实际排查中，可借助 Accesslog 、业务日志、慢请求统计等缩小范围，借助Arthas / JVisualvm等工具的CPU采样功能，筛选可能的业务线程。

生产环境的DEBUG、采样、Dump内存等操作，建议先手动摘流或调小流量权重。