记录工作中遇到的坑以及解决办法

Posted 2021-11-23 exodus3

本地系统运行没问题，之后服务上到测试环境了，测试人员测试一波，然后测试人员就来怼过来了，说卡的一匹，不仅慢，跑个任务等了半个小时，而且数据又不对。
我一惊，本地测试了好多遍，验证过数据没问题，才发布到测试环境的呀。
看了看测试给的数据，一乍，测的几千几万文件，单个文件都几百几千行，难怪要那么久。但是就算再久，也不至于要半个小时才出结果的呀，登录ELK去查看日志。

server_name:"服务名" and message:"关键词"

我的天，ELK居然一直报错，卡住了，叫运维的同事修复一下，运维的同事反馈给我说，我的那个服务当天产生的日志大小有2G了，懵了，赶紧去MoBaxtrm工具去查看。

ps -ef | grep 服务名
查询出该服务的路径
cd 服务路径
ls 查看当前的文件信息
最后看到日志确实有几个G

难怪ELK会炸了，运维的人给我搬了日志路径过来，其实不用搬，我也可以用MoBaxtrm工具去查看的。我还是看一下日志信息有哪些内容，但是我没想到，用谷歌浏览器打开日志文件，谷歌浏览器也卡了，额，i7处理器，32G内存的电脑也会卡成这样。最后费了一些时间，才看到日志信息。内容全是打印文本内容，比如文件上传了，做了什么处理，有很多业务步骤，但是经过这些步骤，都把文本内容打印了出来，难怪会有几个G的日志信息产生。（至于为什么经过那些业务步骤的时候，都要把文本内容打印出来？这是因为每个步骤，每次文本内容都是不一样，经过处理，文本内容是会变的）

于是，赶紧删掉一些日志信息，尤其是文本信息，如果真的要打印文本内容，截取内容的前4000字符比较好。

接着，赶紧定位数据少了的原因，修复了代码。把代码推上了测试环境。测试再搞一波，速度果然快很多，之前30分钟才出结果的，现在2分钟才出结果。我没想到大量的日志信息会影响那么大。测试接着测试更多的文件，数据量更加大，还是没有问题。

另外，发现读取文件的接口异常缓慢，大文件读取速度特别慢，我这边的服务是调用同事读取文件的接口，之前是15s超时，导致没读到文件，我这边就返回来了，导致读取文件是空的，后面就走不下去。现在改成30s超时，另外，同事那边对该接口进行了一番优化，才使服务正常运行下去。

总结：对于这次系统上线测试环境之后，功能异常缓慢，定位问题抽丝剥茧，不像其他网上看到的，JVM调优，一波查看内存占用操作等等，日志信息却是很容易忽略的一个问题。

遇到的坑以及解决办法：
一、文本过大，读取耗时，进行优化。
二、打印了大量日志，打印关键信息，删掉了打印文本内容的日志信息。