记一次线上OOM和性能优化

秒速五厘米 2022-01-12 05:15 324阅读 0赞

某次周五，发布前一周的服务器小动荡?

## 事情回顾 ##

上周五，通过**Grafana监控**，线上环境突然出现CPU和内存飙升的情况：

但是看到网络输入和输入流量都不是很高，所以网站被别人攻击的概率不高，后来服务器负荷居高不下，只能保存dump文件进行分析，并一台一台服务器进行重新启动（还好大家周五下班了）

## 通过日志分析 ##

既然服务器在某个时间点出现了高负荷，于是就先去找一开始出现问题的服务器，去找耗时的服务，例如我当时去找数据库耗时的服务，由于上周的日志已经被刷掉，于是我大致描述一下：

[admin@xxx xxxyyyy]$ grep '15:14:' common-dal-digest.log |  grep -E '[0-9]{4,}ms'
    2018-08-25 15:14:21,656 - [(xxxxMapper,getXXXListByParams,Y,1089ms)](traceId=5da451277e14418abf5eea18fd2b61bf)
    复制代码

上述语句是**查询在15:14那一分钟内，在common-dal-digest.log文件中，耗时超过1000ms的SQL服务**（我上周查的是耗时超过10秒的服务）。

通过**traceId去查Nginx保存的访问日志**，定位在该时间点内，分发到该服务器上的用户请求。还有根据该traceId，定位到整个调用流程所使用到的服务，发现的确十分耗时...

于是拿到了该请求具体信息，包括用户的登录手机号码，因为这个时候，其它几台服务器也出现了CPU和内存负载升高，于是根据手机号查询了其它几台服务器的访问日志，发现同一个请求，该用户也调用了很多次...

## 使用mat进行dump文件分析 ##

通过mat工具对dump文件进行分析，调查是什么请求占用了大内存：

**观察了该对象的引用树，右键选择【class\_ reference】，查看对象列表，和观察GC日志，定位到具体的对象信息。**

通过日志以及dump文件，都指向了某个文件导出接口，接着在代码中分析该接口具体调用链路，发现导出的数据很多，而且老代码进行计算的逻辑嵌套了很多for循环，计算效率低。

查询了该用户在这个接口的所调用的数据量，需要查询三个表，然后for循环中大概会计算个100w+次，导致阻塞了其它请求，线上的服务器CPU和内存使用情况一直飙升。

--------------------

## 代码进行性能优化 ##

在看到该业务在git提交记录是我上一年实习期写的时候，我的内心是崩溃的，当时对业务不熟悉，直接循环调用了老代码，而且也没有测试过这么大的数据量，所以GG了。

然后我就开始做代码性能优化，首先仔细梳理了一下整个业务流程，通过增加SQL查询条件，减少数据库IO和查询数据量，优化判断条件，减少for嵌套、循环次数和计算量。

## 通过jvisualVM进行对比 ##

对比新老代码所占用的CPU和内存状态

**优化前：**

**优化后：**

通过上述优化之后，计算1w条数据量进行导出，在老代码需要48s，新代码也要8s

，不过这是大数据量的情况下，实际用户的数据没有这么多，所以基本上满足了线上99%的用户使用。

当然，由于这些数据是本地开发环境新增加的，与出现OOM问题的用户数据量还有些差别，但通过优化后的代码，**已经在数据库查询的时候就过滤掉很多无效的数据，在for循环计算前也加了过滤条件**，所以真正计算起来起来就降低了很多计算量。

恩，自己优化好了，还要等测试爸爸们测试后才敢上线，这次要疯狂造数据

--------------------

## 开发注意点 ##

在开发一开始的时候，都没有考虑到性能问题，想着满足需求就完成任务，但数据量一大起来，就有可能出现这些OOM问题，所以以后开发时，需要考虑一下几点：

*  梳理设计流程
 *  考虑是否有性能问题
 *  与产品经理商量控制查询条件，减少查询的范围
 *  与数据库交互时，减少无效的查询，合并查询和合并更新操作
 *  减少for循环，尤其注意for循环嵌套问题！
 *  调用老代码要看注意=-=

--------------------

## 吐槽 ##

果然每次看之前写的代码，都有种要si要si的感觉

--------------------

[万元预算玩新机][Link 1] 还有沈大妈的表情真好玩，直接拿来用了~

转载于:https://juejin.im/post/5ce9067df265da1bc4142f18

[Link 1]: https://link.juejin.im?target=https%3A%2F%2Fpost.smzdm.com%2Fp%2F669963%2F%23comments

发表评论取消回复

表情：

评论列表（有 0 条评论，324人围观）

还没有评论，来说两句吧...

相关阅读

相关记一次线上OOM 问题排查过程！

众号后台回复“**学习**”，获取作者独家秘制精品资料 ![640?wx\_fmt=png][640_wx_fmt_png] ![640?wx\_fmt=jpeg][...

ゞ浴缸里的玫瑰/ 2024年04月18日 15:29/ 0 赞/ 19 阅读

相关记一次log4j日志导致线上OOM问题案例

记一次log4j日志导致线上OOM问题案例描述最近一个服务突然出现 OutOfMemoryError，两台服务因为这个原因挂掉了，一直在full gc。还因为这个问

水深无声/ 2024年03月17日 16:42/ 0 赞/ 28 阅读

相关记一次线上OOM故障 Java heap space

1、发现问题早上测试环境一个应用机器容器异常退出，然后开始排查问题，同时查看生产环境是否异常，发现生产程序正常运行，但是内存占用特别大，达到了70%，平时大部分时间保

我会带着你远行/ 2022年12月09日 02:49/ 0 赞/ 412 阅读

相关记录一次线上 OOM

记录一次线上 OOM 事故日期： 2020-11-02 18:30 \\描述：\\最开始是 APP 首页加载报网络超时，后来管理后端也出现了网络超时的情况。个人

阳光穿透心脏的1/2处/ 2022年11月22日 00:29/ 0 赞/ 254 阅读

相关一次线上OOM排查和处理

项目场景：前段时间项目组出现了OOM现象，导致机器重启，部分业务受到影响，这里做一个复盘和总结 -------------------- 问题描述：原因：由

落日映苍穹つ/ 2022年09月09日 06:48/ 0 赞/ 190 阅读

相关记一次网站性能优化的经过

自己的网站 www.ishareread.com 有时候访问快，有时候访问慢，今天访问特别慢。打开首页都要10多秒。一般来说如果一个网站打开页面的速度大于5秒，大家就会失去耐心

蔚落/ 2022年03月26日 04:22/ 0 赞/ 277 阅读

相关记一次线上故障排查

背景描述：平台采用spring-cloud 的微服务框架。用eureka 作为服务注册中心，用zuul 作为网关，在加上两个服务调用者和服务提供者。同时使用ngin

柔光的暖阳◎/ 2022年01月14日 10:05/ 0 赞/ 1064 阅读

相关记一次线上OOM和性能优化

某次周五，发布前一周的服务器小动荡? 事情回顾上周五，通过Grafana监控，线上环境突然出现CPU和内存飙升的情况：但是看到网络输入和输入流量都不是很高，所以网

秒速五厘米/ 2022年01月12日 05:15/ 0 赞/ 325 阅读

相关一次线上Redis性能优化

转载自：[https://www.toutiao.com/a6704950165750415879/?app=news\_article\_lite&is\_hit\_shar

待我称王封你为后i/ 2022年01月09日 09:13/ 0 赞/ 325 阅读

相关又一次线上OOM排查经过

[https://my.oschina.net/flashsword/blog/265442][https_my.oschina.net_flashsword_blog_265

怼烎@/ 2021年06月11日 15:12/ 0 赞/ 543 阅读