进程被kill原因_服务器莫名其妙被kill掉,该怎么办?

近3个月以来,公司的个别应用服务器(java)莫名其妙的出现被kill掉现象,原因各异,排查起来也比较痛苦。那哪些原因会导致JAVA进程被kill呢?该如何去排查问题呢?在这里做个总结,跟大家分享下:

哪些原因可能会导致JAVA进程被kill呢?

  1. Java应用程序的问题:发生OOM导致进程Crash

  2. JVM自身故障:JVM或JDK自身的Bug导致进程Crash

  3. 被操作系统OOM-Killer

该如何去排查问题呢?

  • Java应用程序的问题:发生OOM导致进程Crash

       这种情况主要取决于研发代码质量,我遇到过的大概有2次。一般情况下,出现OOM异常,JVM的GC会进行回收,是不会直接导致JVM进程退出的。如果出现退出的情况,那就是内存泄漏,由于内存占用越来越大,结果。。。。不过这种JVM的OOM导致的异常,很好排查。排查步骤如下:

Step1: 查看JVM参数 -XX:+HeapDumpOnOutOfMemoryError 和 -XX:HeapDumpPath=*/java.hprofStep2: 根据HeapDumpPath指定的路径查看是否产生dump文件;Step3: 若存在dump文件,使用VisualVM这种可视化工具分析就行等工具分析即可;
  • JVM自身故障:JVM或JDK自身的Bug导致进程Crash

        这种情况遇到一次,是因为JDK自身BUG导致的。当JVM出现致命错误时,会生成一个hs_err_pid_xxx.log这样的文件,该文件包含了导致jvm crash的重要信息,可以通过分析该文件定位到导致crash的根源,从而改善以保证系统稳定。当出现crash时,该文件默认会生成到工作目录下,然而可以通过jvm参数-XX:ErrorFile指定生成路径,eg:

-XX:ErrorFile=/var/log/hs_err_pid.log

然根据错误信息,可以进入Java BUG dataBase库中去查找对应的BUG:

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8134389

  • 被操作系统OOM-Killer

     这种情况也遇到过一次。Linux 内核有个机制叫OOM killer(Out-Of-Memory killer),该机制会监控那些占用内存过大,尤其是瞬间很快消耗大量内存的进程,为了防止内存耗尽而内核会把该进程杀掉。可以去/var/log/messages里翻系统报错日志,执行如下命令:

[root@vmt124-m5 /]# egrep -i 'killed process' /var/log/messagesDec 29 00:39:41 localhost kernel: Killed process 26790, UID 0, (java) total-vm:9263796kB, anon-rss:4578020kB, file-rss:20kB

当然,你也可以去内核日志里头查询。有时Linux系统或者系统上运行的java或者其它进程,会发生一些莫名其妙的问题,比如突然挂掉了,比如突然重启等等。在软件上找不到问题所在,此时我们应该怀疑硬件或者内核的问题,此时我们就可以执行 dmesg | grep java 命令来查看:

[root@vmt124-m5 /]# dmesg | grep javajava invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0java cpuset=/ mems_allowed=0Pid: 25475, comm: java Not tainted 2.6.32-220.el6.x86_64 #1[31952]     0 31952  2338119   469643   2       0             0 java[ 2435]  5025  2435   830476    11657   0       0             0 java[26790]     0 26790  2315949  1144510   1       0             0 javaOut of memory: Kill process 26790 (java) score 560 or sacrifice childKilled process 26790, UID 0, (java) total-vm:9263796kB, anon-rss:4578020kB, file-rss:20kB

完全是可以看到内核对进程做对操作。

总结

      对以上异常出现排查的排查顺序一般是:Java应用程序的问题 -> JVM自身故障 -> 被操作系统OOM-Killer

精选案例

  • 数据库CPU过高性能分析

  • 接口调用redis查询慢的问题排查

  • 因内网环境引起的性能问题真的很少

  • SQL结果集性能案例

  • Jmeter_2.12版本引发的一个性能问题

  • 一大早“要出事了”

  • slb连接上不足导致性能问题

  • XX系统OOM问题

  • 在线_php服务瞬间load达到100以上案例分析

  • Cannot assign requested address解决办法

  • 当CPU飙高时,它在做什么

  • 干了件特自豪的事,哈哈

作为一个对性能测试有情怀的人,希望过往的经验能够对新来人有一定的帮助,公众号"性能测试践行"中原创作者日常工作中典型案例和自己每时每刻对性能新的认知,希望喜欢!

e96a128635ad89cd4fbef8c4ce29a040.png

  走过路过,点个在看再走吧~48240e77dfbe03e336f88e427179eaa4.gif

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值