cpu使用率高问题排查与优化-j9九游会登录

场景描述

业务侧rds for mysql实例的sql执行速率在16:08分左右开始变慢，应用有超时的报错。

指标说明

cpu使用率：cpu执行的工作时间的比例。

原因分析

1. 查看cpu使用率监控指标，发现在16:08分左右实例的cpu使用率开始飙升到100%，且一直持续在高位线。
   图1 cpu使用率
   
2. 查看qps、慢sql数以及活跃连接数监控指标，发现在16:08分左右qps突增，活跃连接数上涨，最终业务侧有较多的慢sql产生。
   图2 qps
   
   图3 活跃连接数
   
   图4 慢sql数
   
3. 分析业务类型，查看16:08分前左右innodb的逻辑读速率有突增，且与慢sql的速率趋势相似。
   图5 innodb逻辑读速率
   
4. 登录实例，查看实话会话，发现大量会话在执行select count(*)。

   

   explain确认该sql的执行计划，发现走全表扫描且单条扫描行数在35万 ，其并未走索引。

   

5. 进一步查看该表的表结构，发现该表仅对字段“is_deleted”添加了一个索引“idx_xx_userid”，因此上述查询无索引可选。建议业务侧给字段“idx_user_id”新增索引后，实例在16:37分左右cpu下降到正常水平，业务恢复。

j9九游会登录的解决方案

1. 建议新上业务时，提前对关键sql通过explain、sql诊断等工具进行执行计划分析，根据优化建议添加索引，避免全表扫描。
2. 业务量突增的高并发造成cpu占用率高，可以考虑升级实例规格或使用独享型资源避免出现cpu资源争抢，或者创建只读实例进行读写分离减轻主实例负载。
3. 通过show processlist查看当前会话信息来辅助定位：运行状态为sending data、copying to tmp table、copying to tmp table on disk、sorting result、using filesort的查询会话可能均包含性能问题。
4. 应急场景可以借助sql限流以及kill会话功能来临时kill规避“烂sql”。