前言
最近业务部门有个java服务进程会突然无缘无故的挂掉，然后这个服务会产生一堆类似hs_err_pid19287.log这样的日志。业务部门负责人就把hs_err_pidxxx的日志发给我，让我帮忙看下问题。本文就来回顾一下，我是如何帮业务部门进行问题排查
排查历程
首先hs_err_pidxxx的日志有提示如下内容
f5b4f44942b5fd4ae8fbf26a6682b6f0_92d076f294e2d065092a49361f66ea8c.png
我就让业务部门那边配置下ulimit 。具体步骤如下
vim /etc/security/limits.conf
# 在最后追加
* soft nofile 327680
* hard nofile 327680
不过业务部门负责人跟我反馈说，他们早就加过了，但是不管用。
接着继续分析hs_err_pidxxx的日志内容
d38355b5c3c5079017a942991a58a305_234ecd4209e997f884c0b9605006d109.png
看到新生代的内存出现100%，就问业务负责人说，你们是不是jvm内存设置比较小，结果得到的反馈是他们最近刚进行内存扩容，也进行了相应的jvm设置，内存肯定够，而且程序日志并没有oom的相关日志信息。
于是继续分析hs_err_pidxxx的日志内容，
f0c48bd89c2fdb9fb2146cc64df18fb2_9a7fefd7c4f86661a5a0754740b2e383.png
看着大量的thread_blocked，感觉看到问题要被修复的曙光，于是跟业务负责人说，你们代码可能存在堵塞了，业务负责人说这个服务运行多年了，而且其他机子好好的，如果有这个问题，正常早就暴露出来了。
从这个hs_err_pidxxx日志，我能得到就这些信息。看着业务负责人的由期待再到眼神无光，我大大的感受他有一种所托非人的感觉。后面我跟他说，不然你jdk升级一个小版本，其实我只是试探，毕竟升级jdk，带来收益的时候，可能也带来风险，尤其在运行多年的项目上。没想到业务负责人回答说正有此意。
后面业务负责人就拿那台有问题机子进行jdk升级，事情就暂时告了一段落
问题后续
后来同部门的架构师在某次吃饭和我提起业务部门这个问题，我才发现业务部门升级jdk后，仍然没用。于是业务负责人找了部门的架构师进行求助。知道这个事后，我就主动去找业务部门负责人，问他问题解决没啊，得到他否定的答案后。
本着负责到底的心，我先向他们要来他们宿主机的messages日志。就是位于/var/log/messages。看到如下信息
f6afe7e6510a80d46bd0a27c8eacb2b6_cc8466e6863522394e7745070468f3fd.png
里面日志有个abrt-server。这边科普一下。
什么是abrt-server
abrt是centos操作系统中的一个错误报告和跟踪工具。它可以自动收集应用程序和系统的错误信息，并生成错误报告。当系统发生错误时，abrt会收集相关的信息，如错误消息、堆栈跟踪、核心转储等。它会生成一个错误报告，包含了这些信息以及其他有用的调试信息。
它的记录保存在内核core文件，随着时间推移，core文件会不断变大，会占用磁盘空间。我们可以使用 abrt-cli list 确认core状态对应的进程及触发时间。并通过abrt-cli rm 【文件包】进行删除
示例：
abrt-cli rm /var/spool/abrt/oops-2022-09-27-14:22:55-13596-0
回归正题，我们通过/var/log/messages里面的内容
362939e5ffdd4b72276bb28c7cf9b886_8c34fc9f1359175a77ad074534e4eeb5.png
通过搜索资料，得知这个错误是因为无法创建ccpp文件导致。但这个是不是导致java进程频繁挂掉的原因，于是我们做了这么一步，将无法创建ccpp文件的时间点和生成的hs_err_pidxxx时间点做个对比
e50edf08baa1cbbe386a5d99058f93b3_a435fe86d8636007fa4f131c49e87471.png
时间点基本上是吻合的，而且/var/log/messages里面还有一段
Executable '/usr/local/tomcat/jdk1.8.0_291/bin/java' doesn't belong to any package and ProcessUnpackaged is set to 'no'
后与业务负责人确认，这个jdk确实是目前这个业务所使用的jdk。综上基本上可以确定是因为无法创建ccpp文件导致，导致该业务的java进程频繁挂掉的原因之一
如何修复
方法一：将ProcessUnpackaged改为yes
这个参数的意思是表示ABRT将非rpm安装程序（如源代码包等）识别为未打包程序，会生成相关的警告和错误日志，因而会更好地抓住一些程序的 bug。如果为no，表示ABRT将不会跟踪和报告那些在未打包的应用程序中发生的崩溃信息，而只针对现有的软件包进行跟踪。因此，使用yes选项能够扩展 ABRT 的范围，提高异常程序的捕捉数量，但同时可能也会导致一些误报
sed -i 's/ProcessUnpackaged = no/ProcessUnpackaged = yes/g' /etc/abrt/abrt-action-save-package-data.conf&& systemctl restart abrtd.service
或者分步执行也可以
vim /etc/abrt/abrt-action-save-package-data.conf
ProcessUnpackaged = yes
systemctl restart abrtd.service
不过这边还有个细节要注意，核心转储文件的默认最大大小为5000，我们可以按实际情况调整，也可以设置为0，为0表示核心转储文件的大小不作限制，不过设置为0有个风险点是可能会磁盘空间占满，因为core的文件正常比较大
可以通过如下配置，修改MaxCrashReportsSize参数
vim /etc/abrt/abrt.conf
MaxCrashReportsSize = 0
systemctl restart abrtd.service
或者执行如下命令
sed -i "s/MaxCrashReportsSize = 5000/MaxCrashReportsSize = 0/g" /etc/abrt/abrt.conf && systemctl restart abrtd.service
方法二：禁用abrtd
abrt-hook-ccpp在进行执行崩溃转储操作时，使用的内存有可能会超过预期或系统能够提供的内存限制，导致影响其他应用程序。因此我们也可以直接执行如下命令，禁用abrtd
systemctl stop abrt-ccpp.service
systemctl disable abrt-ccpp.service
systemctl status abrt-ccpp.service
总结
执行了如上操作，业务部门观察了一段时间，没有再发现java进行频繁挂掉问题。
此外不管是容器化部署还是传统的宿主机部署，当出现问题时，没头绪时，我们可以通过查看/var/log底下的各种日志进行梳理。如下链接
https://www.cnblogs.com/deverz/p/8779357.html
是各种var/log的描述说明，感兴趣的小伙伴可以看看
网友评论