前言

最近经常有小伙伴问我,遇到了线上问题要如何快速排查。

这非常考验工作经验了。

有些问题你以前遇到,如果再遇到类似的问题,就能很快排查出导致问题的原因。

但如果某个问题你是第一次遇到,心中可能会有点无从下手的感觉。

这篇文章总结了,我之前遇到过的一些线上问题排查思路,希望对你会有所帮助。

1 OOM问题

OOM问题在生产环境中,一旦出现,一般会是非常严重的问题,服务可能会挂掉。

但是OOM问题有多种情况,不同的情况,出现问题的原因不一样。

1.1 堆内存OOM

服务器的日志一般会打印下面的内容:

java.lang.OutOfMemoryError: Java heap space

这种是出现最多的OOM问题。

在Java服务启动时,可以增加下面的参数:

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=heapdump.hprof

在发生OOM时,程序会自动把当时的内存使用情况,dump保存到指定的文件。

然后使用MAT(Memory Analyzer Tool),或者使用JDK自带的 Java visualvm,来分析dump 文件,找出导致OOM 的代码 。

1.2 栈内存OOM

出现栈内存OOM问题的异常信息如下:

java.lang.OutOfMemoryError: unable to create new native thread

如果实际工作中,出现这个问题,一般是由于创建的线程太多,或者设置的单个线程占用内存空间太大导致的。

这个时候需要排查服务的线程数量。

推荐使用线程池,可以减少线程的创建,有效控制服务中的线程数量。

1.3 栈内存溢出

出现栈内存溢出问题的异常信息如下:

java.lang.StackOverflowError

该问题一般是由于业务代码中写的一些递归调用,递归的深度超过了JVM允许的最大深度,可能会出现栈内存溢出问题。

如果生产环境中,出现了这个问题,可以排查一下递归调用是否正常,有可能出现了无限递归的情况。

1.4 GC OOM

出现GC OOM问题时异常信息如下:

java.lang.OutOfMemoryError: GC overhead limit exceeded

GC OOM一般是由于JVM在GC时,对象过多,导致内存溢出,建议调整GC的策略。

在老代80%时就是开始GC,并且将-XX:SurvivorRatio(-XX:SurvivorRatio=8)和-XX:NewRatio(-XX:NewRatio=4)设置的更合理。

1.5 元空间OOM

出现元空间OOM问题时异常信息如下:

java.lang.OutOfMemoryError: Metaspace

JDK8之后使用
Metaspace
来代替
永久代
,Metaspace是方法区在HotSpot中的实现。

这个问题一般是由于加载到内存中的类太多,或者类的体积太大导致的。

如果生产环境中出现了这个问题,可以通过下面的命令修改元空间大小:

-XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=10m

我在这里列举了OOM问题的最常见的情况,大家如果想了解更多,可以看一下我之前写的一篇文章《
工作中最常见的6种OOM问题
》,里面有更详细的介绍。

2 CPU100%问题

线上服务出现CPU100%问题,也很常见。

出现这个问题,是由于服务长时间占用CPU资源导致的。

主要原因有下面这几种:

定位这个问题,可以使用JDK自带的
jstack
工具,或者用阿里开源的
Arthas
探测工具。

如果对CPU100%问题比较感兴趣,可以看看我的另一篇文章《
糟糕,CPU100%了!!!
》,里面有更详细的介绍。

3 接口超时问题

不知道你有没有遇到过这样的场景:我们提供的某个API接口,响应时间原本一直都很快,但在某个不经意的时间点,突然出现了接口超时。

导致接口超时的原因有很多,我们需要挨个逐一排查。

下面这张图中给大家列举出现了,生产环境接口突然出现超时问题时的常见原因:

如果大家想进一步了解接口超时问题,可以看看我的另一篇文章《
接口突然超时10宗罪。。。

4 索引失效问题

不知道你有没有遇到过,生成环境明明创建了索引,但数据库在执行SQL的过程中,索引竟然失效了。

由于索引失效,让之前原本很快的操作,一下子变得很慢,影响了接口的性能。

我们可以通过
explain
关键字,查看sql的执行计划,可以确认索引是否失效。

如果索引失效了,可能是哪些原因导致的问题呢?

下面这张图给大家列举了常见原因:

想进一步了解索引失效问题的小伙伴,可以看一下我的另一篇文章《
聊聊索引失效的10种场景,太坑了
》,里面有非常详细的介绍。

5 死锁问题

如果你使用的是MySQL数据库,在生产环境肯定遇到死锁问题。

死锁
是指两个或多个事务在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用,这些事务将无法继续向前推进。

在Java中,使用MySQL数据库时,如果遇到MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction异常,意味着数据库检测到了死锁。

MySQL死锁通常由以下原因造成:

  • 资源竞争:多个事务同时竞争相同的资源,比如都试图获取对方持有的锁。
  • 循环等待:事务之间形成了一种互相等待对方释放资源的循环关系。
  • 不当的事务设计:事务执行顺序不合理、执行时间过长等。
  • 并发操作冲突:在高并发环境下,多个事务对同一组数据进行操作,容易引发锁冲突导致死锁。
  • 索引使用不当:如果索引设计不合理,可能导致事务在获取锁时出现问题。

如何减少死锁问题?

  1. 设置合理的事务隔离级别。
  2. 避免大事务的业务代码。
  3. 优化sql性能。
  4. 增加锁等待超时处理。
  5. 增加监控和分析

6 磁盘问题

服务器磁盘问题是众多线上问题中,最好排查的了。

磁盘问题一般有两种:

  1. 磁盘坏了
  2. 磁盘空间不足

如果是磁盘坏了,运维一般在短时间内,很难及时修复好。

因此,需要及时更换磁盘。

如果是磁盘空间不足。

一般需要登录到那台服务器,
使用命令:

df -Hl

查看当前服务器的磁盘使用情况。

  • 总大小
  • 已使用多少
  • 可用多少

最快的解决办法是,将/tmp文件夹中的文件删除,可以释放一些磁盘空间。

然后找到日志文件,删除7天以前的日志。

这两种方式,一般会释放不少磁盘空间,暂时解决磁盘空间不足的问题。

从常用来看,我们需要对服务器的磁盘使用情况做监控,如果超过阀值有预警。

同时需要需要规范业务系统,哪些场景需要打印日志,哪些场景不需要,不应该所有的场景,都打印日志。

特别是有些业务查询接口调用非常频繁,一次性返回的数据很多,这种情况下,会导致服务器上的日志迅速膨胀,占用过多的磁盘空间。

7 MQ消息积压问题

如果你使用过MQ消息中间件,在生产环境肯定遇到过MQ消息积压问题。

出现这个问题,一般是MQ消费者消费消息的速度,比MQ生产者生产消息的速度慢。

如果之前一直都是好好的,突然有一天出现了MQ消息积压问题。

可能是下面的原因导致的:

  1. MQ生产者批量发送消息。
  2. 随着数据越来越多,MQ消费者的在处理业务逻辑时,mysql索引失效或者选错索引,导致处理消息的速度变慢。

如果生产环境出现MQ消息积压问题,先确认MQ生产者有没有批量发送消息。

如果有,则可以把MQ消费者中线程池的核心线程数和最大线程数调大一些,让更多的线程去处理业务逻辑,提升消费能力。

这套方案的前提是MQ消费者中,已经使用了线程池消费消息。

如果没有使用线程池,则只能临时增加服务器节点了。

如果MQ生产者没有批量发送消息,则需要排查MQ消费者的业务逻辑中,哪些地方出现了性能问题,需要做代码优化。

优化的方向是:

  1. 优化索引
  2. 优化sql语句
  3. 异步处理
  4. 批量处理

等等,还有其他的。

如果大家对性能优化的技巧比较感兴趣的小伙伴,可以看看我的另一篇文章《
我用这11招,让接口性能提升了100倍
》,里面有非常详细的介绍。

8 调用接口报错

我们生产环境的程序,有时候会出现,之前调用某个API一直都是正常的,但突然出现报错的情况,即返回码不是200。

那么,这种问题,我们该如何排查呢?

8.1 返回401

一般生产环境出现这个问题,是由于没有通过接口的登录认证。

出现这种情况,一般用户在尝试访问受保护的资源前,需要通过某种形式的身份验证(如登录),但如果未能正确提供必要的认证信息,如Token、用户名和密码等。

就会出现返回码是401的情况。

8.2 返回403

如果生产环境请求某个接口,返回码是403,则说明目前没有访问资源的权限。

这种场景跟返回码是401有区别。

401着重于认证问题,即用户没有提供正确的身份验证信息。

而403则是在认证成功的基础上,用户没有足够的权限去访问请求的资源。

要解决这个问题,我们需要给接口的调用方,分配相应的访问权限。

8.3 返回404

不用怀疑,你请求的接口地址,现在已经不存在了,才会报404。

比如有些接口名称改了,或者接口路径中/v1/user/query改成了/v2/user/query,版本号升级了。

如果没有通知所有的接口调用方,都可能会出现请求接口返回码为404的情况。

还有一种可能也会导致请求接口报404的问题,接口地址之前注册到了API网关中,但API网关的配置出现了问题。

优先排查接口url是否修改,然后排查网关或者Nginx配置是否有问题。

8.4 返回405

如果请求的接口,返回码为405,一般是请求方式错误导致的。

最常见的是:接口只支持post方式,但发送的却是get请求。

或者接口只支持get方式,但发送的却是post请求。

这种问题一般非常好排查和解决。

8.5 返回500

如果请求的接口,返回码为500,一般是出现了服务的内部错误。

一般网关层会对接口的返回值做一次封装,不会返回真正的异常信息。

我们只能查看接口的错误日志,来定位和排查问题。

建议出现异常时,把接口请求参数打印出来,方便后面复现问题。

导致这种问题的原因有很多,我们只能根据服务器上的错误日志,和相关的业务代码逐一排查。

8.6 返回502

如果请求的接口,返回码为502,一般是出现了服务不可用的情况。

有两种情况:

  1. 服务器正在重启中。
  2. 服务挂掉了。

这时候可以查看一下服务的监控,也可以登录到服务器上查看的运行状态。

大部分情况下,重启一下服务,可以快速解决问题。

然后再根据服务器上的日志,可以定位具体的原因,比如:OOM问题导致的。

8.7 返回504

如果请求的接口,返回码为504,一般由于网关或者接口超时导致的。

接口返回数据的耗时,大于网关设置的超时时间,就会出现这个问题。

出现这种情况,一般需要优化接口相关的代码。

如果大家对接口优化,比较感兴趣可以看看我的这篇文章,《
我用这11招,让接口性能提升了100倍
》,里面有非常详细的介绍。

如果你对日常工作中的一些坑,比较感兴趣,可以看看我的技术专栏《
程序员最常见的100个问题
》,里面有很多干货,还是非常值得一看的。

最后说一句(求关注,别白嫖我)
如果这篇文章对您有所帮助,或者有所启发的话,帮忙扫描下发二维码关注一下,您的支持是我坚持写作最大的动力。

求一键三连:点赞、转发、在看。
关注公众号:【苏三说技术】,在公众号中回复:面试、代码神器、开发手册、时间管理有超赞的粉丝福利,另外回复:加群,可以跟很多BAT大厂的前辈交流和学习。

标签: none

添加新评论