取经阿里十年技术大佬,得到Java线上问题排查攻略!

Posted Java鱼仔

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了取经阿里十年技术大佬,得到Java线上问题排查攻略!相关的知识,希望对你有一定的参考价值。

本文收录于JavaStarter ,里面有我完整的Java系列文章,学习或面试都可以看看

(一)前言

再牛逼的程序员都写不出完美无缺的代码,作为后端开发工程师,一不小心就会遇到线上故障。如果线上故障处理不及时,就可能导致各种严重的后果。恰好最近部门出现了一次挺严重但幸运的是影响面不大的线上故障,最后在阿里工作十年的leader分享了线上问题的排查思路。结合这次分享,写下了这篇Java线上问题排查攻略。

(二)问题发生后的首要工作

一般来说,线上的问题在发生之前会有一系列的预警,比如CPU被打满,网络达到顶峰等等问题。然后就是客户或者用户的反馈,比如某某页面打不开,系统加载很慢,一直提示报错等等。

这个时候的应急操作是首先记录问题发生时的情况:包括服务器的情况,Java虚拟机的一些情况,数据库的连接情况等等,然后尽快让用户能正常使用系统。常用的方法就是系统降级:即让出问题的服务先停掉。或者代码回滚:往往问题都是在代码更新后出现的。或是重启大法,要尽快的保证用户能正常使用。

(三)线上问题异常及可能的原因

出现问题时最先需要记录的是线上的各项异常指标。

3.1 应用层面

应用层面的排查主要是CPU、load、内存以及网络

3.1.1 CPU

top命令查看CPU占用情况,基本参数如下:

如果发现CPU占用率很高,这个时候就要考虑CPU跑满的原因:

1、FULL GC 频繁

2、有非常耗CPU的操作

同时,可以通过一些命令将CPU占用最高的几个线程查看出来

ps -ef | grep java 或者 jps 找到pid
top -Hp pid 找到使用CPU最高的线程
printf '0x%x' tid 线程id转化为16进制
jstack pid |grep tid 找到线程堆栈

除此之外,也可以使用一些外部的检测工具比如arthas

3.1.2 Load

load指的是一段时间内CPU正在处理及等待的任务数,也是通过top命令:

load average: 0.14,0.21,0.35,分别表示1分钟、5分钟、15分钟内系统的平均负荷。

Load会有两种场景:

CPU高,Load高:先查CPU利用率的问题

CPU不高,Load高:大部分情况都是因为磁盘读写请求过多导致大量IO等待,可通过:

jstack -l pid | grep BLOCKED 查看阻塞态线程堆栈

3.1.3 内存

内存的异常往往可以通过报错得知,常见的异常有如下几种:

OutOfMemoryError:java heap space
OutOfMemoryError: GC overhead limit exceeded  默认情况下, 如果GC花费的时间超过 98%, 并且GC回收的内存少于 2%, JVM就会抛出这个错误
OutOfMemoryError:permgem space 元数据大小超过jvm参数配置
OutOfMemoryErrorMetaspace 元数据大小超过jvm参数配置
java.lang.StackOverflowError 一般线程栈溢出是由于递归太深或方法调用层级过多导致的

排查流程如下:

1、查看当前jvm内存的参数配置:jmap -heap pid

2、查看gc情况:jstat -gcutil pid

3、内存dump:jmap -dump:format=b,file=/tmp/dump.dat pid 这个命令在线上慎用,会导致系统变慢

4、内存分析工具分析

3.1.4 网络

出现网络问题的现象主要有两点:

1、http链接无法建立,有大量close_wait的tcp连接

2、tcp重传率高

关于网络问题,我在上家公司刚好遇到过,大量的等待tcp连接导致系统濒临宕机,后来发现是网络带宽500M变成了200M的问题。

3.2 数据库层面

除了应用之外,第二点可能会出现问题的就是数据库了

3.2.1 CPU打满

数据库服务器的cpu被打满,原因可能是:

1、大数据量查询没有走索引,导致慢sql的出现

2、sql中存在各种导致索引失效的操作

问题解决方式:

通过运维工具(比如rds)找到sql执行时间最长的top10,通过explain查看sql执行是否走了索引,然后加索引优化。

3.2.2 网络流量飙升

原因可能是:

1、sql没有设置limit导致全部数据返回

2、sql的请求数量快速增加

解决方式:

1、在搜索代码中务必加上limit

2、运维工具查看异常时间段的sql执行情况

3.2.3 系统资源正常,sql一直阻塞

原因可能是:

1、一些sql操作导致锁表

解决方式:

1、通过数据库监控工具查找执行时间长的sql

2、将执行时间长的sql直接kill掉

(四)总体的问题排查流程

第三节主要介绍了详细的问题产生可能原因以及解决办法,这一节主要讲问题的排查流程:

4.1 及时收集信息

问题的故障点是很重要的,如果不清楚问题发生的原因,那就说明下次依旧可能发生,因此要将故障信息尽快收集起来,同时做好应用的监控。

4.2 定位原因

问题发生百分之95的原因是近期做了变更,思考近期变更的地方:

1、代码是否有更新

2、数据库是否有变更

3、网络是否做了切换

4、其他应用是否会影响你的应用

5、是否有流量突然变大的情况

同时收集日志、通过工具辅助定位原因,常用的工具有arthas

4.3 快速响应

在尽可能快的时间里将系统还原:

1、如果是代码更新导致,回滚代码

2、如果是数据库变更导致,切换回来

3、如果是网络做了调整,联系网管

4、如果是其他应用的影响,联系其他应用降级

5、如果是流量突然增大,限流

6、实在不知道怎么办,重启

(五)总结

当问题出现时,主要负责人很可能会慌到大脑一片空白,这个时候一定要有人一起解决问题。按照排查的思路,一步步排查。另外很多事故可能是因为一些简单的问题导致,比如网络带宽、索引失效,因此从一些小的问题点出发。另外整个流程有一张脑图,如果需要的话可以联系我。我是Java鱼仔,我们下期再见!

以上是关于取经阿里十年技术大佬,得到Java线上问题排查攻略!的主要内容,如果未能解决你的问题,请参考以下文章

Java线上故障排查不会怎么办,p8大佬总结的套路清单带你轻松玩转!

阿里云K8s容器Pod中Java进程CPU占比100%排查(线上JVM排查之一)

阿里云K8s容器Pod中Java进程CPU占比100%排查(线上JVM排查之一)

阿里云ARMS排查ACK容器环境Java事务阻塞触发系统连锁雪崩故障(线上JVM排查之六)

阿里云ARMS排查ACK容器环境Java事务阻塞触发系统连锁雪崩故障(线上JVM排查之六)

阿里云ARMS排查ACK容器环境Java事务阻塞触发系统连锁雪崩故障(线上JVM排查之六)