系统后台服务突然变慢，怎样排查诊断？

最新推荐文章于 2024-04-23 19:50:58 发布

小龙coding

最新推荐文章于 2024-04-23 19:50:58 发布

阅读量1.3k

点赞数

分类专栏： BAT大厂面试系列文章标签： java 后端架构分布式

本文链接：https://blog.csdn.net/qq_43666365/article/details/121712473

版权

BAT大厂面试系列专栏收录该内容

12 篇文章 1 订阅

订阅专栏

微信原文：系统后台服务变慢，怎样排查诊断？

微信公众号：小龙coding

关注选择星标，重磅干货，第一时间送达！

如果你觉得文章对你有帮助，欢迎关注，在看，点赞，转发！

关注下方公众号【小龙coding】回复【基于人工智能的校园助手】领取大厂面试精品项目，【助力礼包】领取鹅厂大佬秋招面试助力礼包。

前文

大家好，我是小龙。

事情是这样的，因为之前面试百度二面时被面试官问过这样一个场景题 “假如你项目后台服务突然变得很慢，你该怎样去排查和解决呢？”，当时没真正遇到过这种问题，所以只能根据自己的相关经验去 “吹” ！，感觉回答的不是很到位。

正好最近在负责一个项目，今天测试时发现系统后台服务变的出奇的慢，于是便自己去排查诊断了一翻。这方面我也不太熟悉，就试着去检查了一番。在此分享一下我当时排查的过程，感觉非常有意义。

一般在公司中，对实现一个系统完善的日志、性能等监控系统都比较重视，因为当线上线下出现问题时，最好最快的方式就是排查日志，查看相关监控系统。

然后我还利用了一些Java诊断工具去监控系统发生的异常，比如JFR，随时监控系统是否出现大量某种异常，如果有，那么这个异常可能就是突破点。

在你看来，可能做这些额外的监控系统，日志可能比较浪费时间，没必要。但是在我个人项目中，我特别重视这一点，因为事前做好充分准备，当真正发生了故障，我便可以凭借此快速定位到问题。

排查思路

查看错误日志

回过来，我开始想的就是可能是后台服务程序自身出了问题，于是最先想到的就是去检查应用本身的错误日志，从部分日志并没有发现有什么明显的异常，然后在并发量太大的情况下，查日志也会很慢。

CPU

然后到后台服务器监控平台，查看系统资源是否达到上限，例如：CPU、内存、磁盘、I/O、网络带宽等。我是从上到下看的，网络，系统，应用。任何一个环节都有可能有问题,首先看网络监控情况，然后看系统（内存，cpu,负载）情况。此处补充如何排查CPU、内存相关问题。

启动程序之前通过 HeapDumpOnOutOfMemoryError 和 HeapDumpPath 这两个参数开启堆内存异常日志
```
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=
```
从日志从发现异常
再通过 top -Hp pid 查看进程下所有具体线程占用系统资源情况。
再通过 jstack pid 查看具体线程的堆栈信息（线程ID、状态（wait,sleep）,是否持有锁）
再通过 jmap 查看堆内存的使用情况 jmap -heap pid
通过以上命令分析基本可以看出什么问题导致内存上升，现在分析问题产生的原因
我们在启动时，已经设置了 dump 文件，通过 MAT 打开 dump 的内存日志文件，分析即可。

然后，我直接大致定位到具体应用，再把线程dump出来，根据以上一系列操作，查看线程是否存在问题，有没有死锁，卡代码等问题。

磁盘

对于服务器磁盘空间问题，当时实习时，也有幸遇到过，积累了一些经验，在此顺便做个分享：

查看磁盘空间

df -h

发现某个路径已经占了100%，切换根目录查看空间

du -h --max-depth=1

然后再看该目录下哪个文件占用空间最大，然后切换到该目录，继续使用以上命令查看，以此循环直到找到问题，最后发现日志打满了。

然后磁盘有一些目录基本为空，而这个目录几乎达到100%，于是建立了一个软链接指向空目录，顺便删除了一些废弃日志。

然后重新测试，还是不太行。

继续往下排查。。。。

内部服务器配置，SQL等

接着去检查应用服务器（Tomcat）的线程池配置是否合理，看了一下请求的排队现象是否严重，如果严重则需要重新设置合理的线程池。同样，检查一下数据库的连接池设置是否合理，增大连接池设置，同时检查一下是否有慢sql，如果有慢sql，则进行优化（优化方案是查看执行计划，设置合理的索引等）

对于慢SQL如何优化，此前写过一篇文章专门介绍，此处不过多赘述。然后发现一些SQL存在一些问题，修正了一翻，但是问题也不太大，不是主要原因，于是，接着往下分析。

字节面试官：一条sql执行慢的原因？如何优化？

服务调用

由于分布式服务一般都是服务治理的，可以看整个调用链的时间图，于是我去查看了访问慢的服务的调用链，查看一下调用链中的每一步响应时间是否合理，发现有个服务响应时间明显长于其他，然后去查看其中的问题，排查了一个超时的服务，发现是Redis大量连接超时，我去，之前为啥没想到。然后又去看为啥Redis大量连接超时，最后发现是网络的问题，然后又去排查网络相关的问题。

然后我去找了临近的防火墙看对应服务器的并发连接数是否新建连接/半开连接超高，或者有突发流量挤占了资源。后来重启了有问题的服务器，就谜一样的解决了。

虽然感觉有点乌龙，但是我还是想给大家分享一下排查问题的思路，当我们遇到问题时，可以从哪些地方着手考虑。当然，我也是半吊子，不过大家可以一起学习探讨，如何更优更快更直接找到问题所在。

评论区欢迎留言，下面有个 ”写留言“ 哟！！！