龙叔运维问题排查记录异常数据导致weblogic线程stuck/OOM

Posted 2022-05-19 龙叔运维

最近整理历史处理过的问题  看到了当时16年刚毕业入司那年遇到的一个比较有意思的问题，这里记录下，也是一个问题排查的思路

 

现象

是一个生成pdf函件的系统。后文都称为【pdf生成系统】，功能很单一，就是根据传过来的参数，然后用不同的模板（jasper模板）生成各种pdf

有一天突然出现一个实例GC回收告警，GC回收不了，监察日志发现实例出现大量stuck线程，过了一会就把内存耗尽OOM了，重启后有效，但是总是在不同的实例上出现，而且只是一个实例，从这一点基本就可以判定是一条异常数据导致的，这条异常数据不断尝试，不断出问题，处理的线程无法释放导致的

于是两个方向走，一遍排查这个异常数据，一边如果再次出现，立马重启，毕竟要保证生产正常

（运维的第一任务就是保证生产正常，一切工作都是基于这个哦，这是运维铁律，如果系统都不正常，再多出彩的加分项工作都是无用的，这也是我毕业之后第一个领导教我的，一直作为我的运维准则）

排查

因为对weblogic比较熟，所以立马就想到了stuck线程的概念：如果执行线程处理某个请求的粘滞时间超过了配置的粘滞线程最大时间，stuck线程，粘滞线程最大时间是在weblogic配置的，默认是600秒

所以如果日志里面打印出了stuck线程的日志，那么就可以根据stuck日志打印的时间，以及当前堵塞的时间来倒推这个请求开始的时间，stuck日志如下：

那么倒推这个请求的时间就是   18：15：56   减去  940秒，也就是请求产生的时间大概在18：00：16左右

打印pdf有一个tracer日志，里面记录了每次调用开始打印的记录：，根据18：00：16这个时间查找日志，于是找到了最符合的这一单数据

那么如果这一单一直在重试，肯定不会只有这一个记录，于是又搜了别的异常过的实例，都搜到了这个异常单，一直在不断的重试

其实这个时候就已经可以确定这个异常单了，但是可以再确定下这个异常单到底有没有生成pdf，就去搜了下out日志（所有pdf生成成功都会再这个日志记录，如下图，对应单号都会有export done 打印成功的日志）

果然没有搜到这一个异常数据生成pdf的记录

 

 

处理&原因

最后核实这一单的数据，是上游调用系统前端录入了错误的信息，导致传了错误的关键字信息给【pdf生成系统】，后台根据不同条件会调用不同的子模板去生成pdf，这个异常单因为数据不对，调用了错误的子模板，导致子模板的长度超过父模板，于是无法生成pdf

而上游系统每小时都会对未生成pdf的单再次补处理，于是每次调用都会导致一个实例产生stuck线程，stuck线程会一直占用一个对象，导致最后OOM。

最后是上游系统对这一单的数据做了修改，问题就解决了

 

当然，系统也是需要做优化的，上游系统需要对录入做最基本的校验，【pdf生成系统】也需要做一些容错处理，不应该因为一单异常数据，就导致服务异常

 

推荐公众号,分享运维知识：龙叔18岁