-
单台或个别机器突然CPU升高
先排除网络波动,部分机器处于失效状态,流量集中在部分机器上
检查GC情况,FullGC突然增加,检查一下连接数据库连接的情况,排除sql集合过大影响。
检查定时任务,定时任务错峰执行
消息、请求堆积后恢复时的瞬时流量引起,减少消费线程
-
单台或个别机器突然LOAD升高
锁资源争抢,代码上下文复杂度低,导致大量线程停留在上锁代码处竞争锁,使用jstack或kill -3导出所有线程调用栈,是否有较多线程停留在相同方法区
云机与docker同时伴随着ST升高,说明式宿主机的其他容器正在抢占资源
线程循环调用,查看虚拟机下的线程状态,长期运行中且较高CPU使用率的都是可疑线程,使用top -Hp等命令可以过滤出这一类线程,通过导出调用栈来确定循环位置
IO等待,检查Blocked的线程,定位代码逻辑。可以通过缓存方式单线程写入优化IO写入。
检查GC情况,如果使用了CMS,持续观察LOAD升高时的是否存在CMS并发收集情况。可优化CMS的配置,如清理阈值,内存整理等
死锁排查
-
内存使用异常
公网机器先检查连接情况,排除大量失效连接未断开引起的问题
jstat -gcutil 命令观察启动内存负荷与GC情况,对于异常发生时,老年代上升很快,需要确定是否由PretenureSizeThreshold配置引起的,导出内存,找出大对象
检查堆外内存使用,一些缓存工具可能会使用堆外内存减少对GC的影响。netty也可以选择使用池化堆外内存。
打开GC日志,观察YGC后是否有对象晋升到老年代,评估内存泄漏可能
出现PermGen space关键字d,一般是SPRING代理过多导致了1.6版本的Perm空间溢出,检查类加载情况
空间分配不合理,引起对象过早进入Old,检查空间分配和老年代晋升配置,配合GC日志优化配置
集合频繁扩容,用map或collection通信时,多次扩容容器,产生大量内存对象,伴随CPU上涨
内存泄漏,多数发生于无界队列问题,消费缓慢导致队列无上限增加
-
RT升高业务响应变慢
1.8以下排除hash冲突引起的单链表过长的问题
消费线程池满,导致新进入的请求无法处理,扩大线程池,定位调用链路,减少调用链路中阻塞
慢查询、数据库死锁引起连接池满,大量请求堆积。查看日志、数据库慢查询日志与数据库当前连接情况,是否存在上述情况
排除缓存击穿情况,验证数据库访问量是否上升
-
吞吐量下降、SI过高
检查核心中断情况,是否大量中断都集中在个别CPU上
内核信息获取会有内核锁,部分监控会读取内核信息从而导致软中断抖动,观察进程与SI之间变化可找到影响
-
间歇性无法启动或异常重启后出现(消失)
类冲突、找不到方法的异常多数是JAR包冲突引起的,或MAVEN中低版本的代替了高版本引起的。通过日志定位异常类,使用工具找到冲突包,如arthas等即可轻松解决
-
慢查询(MYSQL)
伴随limit与order by往往是全量扫描,全量扫描附加条件往往无法命中索引,建议使用主键排序,后根据前一次的最大最小主键id再次约束范围,其他条件语句将会被优化到排序后。
线上异常排查总结
最新推荐文章于 2024-01-05 08:30:00 发布