专栏首页司夜的专栏记录一次应用被突然kill掉的问题定位经历
原创

记录一次应用被突然kill掉的问题定位经历

问题背景:一次启动本地应用,两分钟过后自动退出,通过日志并未发现任何异常状况,莫名其妙的应用就自动被杀掉了;

解决思路:

1、linux通过top查看java应用内存和cpu都不高,只是过一会突然就没了;

2、通过应用日志并未查到有任何异样,代码也走查了好几遍;

3、通过dmesg | grep java查看内核日志信息,发现了问题所在,如下:

[16949523.941194] java invoked oom-killer: gfp_mask=0xd0, order=0, oom_score_adj=991
[16949523.942914] java cpuset=73a35980233979bb67f20700c76d77805de6ced7cfd18de836238a7bdae7c1dd mems_allowed=0
[16949523.942918] CPU: 4 PID: 310033 Comm: java Tainted: G     U     O 3.10.107-1-tlinux2_kvm_guest-0052 #1
[16949523.971234] Memory cgroup out of memory: Kill process 310033 (java) score 1964 or sacrifice child
[16949523.973103] Killed process 182650 (java) total-vm:16705124kB, anon-rss:2079844kB, file-rss:22020kB

以上信息可以看到内存溢出被linux杀掉的java应用信息;

4、但是我应用内存占用并不是特别高,通过jinfo -flags <javapid>发现java应用的启动预申请内存达到了10G;

启动参数

5、通过free或者vmstat查看剩余内存大小只有10G了,内核检测到系统内存不足、挑选并杀掉某个进程的过程可以参考内核源代码 linux/mm/oom_kill.c,当系统内存不足的时候,out_of_memory() 被触发,然后调用 select_bad_process() 选择一个 “bad” 进程杀掉,如何判断和选择一个 “bad” 进程呢,总不能随机选吧?挑选的过程由 oom_badness() 决定,挑选的算法和想法都很简单很朴实:最 bad 的那个进程就是那个最占用内存的进程。

 6、oom_kill.c 代码里可以看到 oom_badness() 给每个进程打分,根据 points 的高低来决定杀哪个进程,这个 points 可以根据 adj 调节,root 权限的进程通常被认为很重要,不应该被轻易杀掉,所以打分的时候可以得到 3% 的优惠(adj -= 30; 分数越低越不容易被杀掉)。我们可以在用户空间通过操作每个进程的 oom_adj 内核参数来决定哪些进程不这么容易被 OOM killer 选中杀掉。比如,如果不想 MySQL 进程被轻易杀掉的话可以找到 MySQL 运行的进程号后,调整 oom_score_adj 为 -15(注意 points 越小越不容易被杀)

7、oom_score_adj设置值范围-1000 到 1000范围区间,设置举例:当某一个应用内存申请占用1G时,设置oom_score_adj=-500时,实际linux会认为该应用只用了500M,会有个打折机制;以确保某些重要应用不会被意外kill掉;

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 为什么我的进程被kill掉了

    这段代码非常简单,就是先用mmap的方式,为该进程分配10GiB的虚拟内存,然后再用page写的方式,让操作系统为这10GiB虚拟内存,分配对应的物理内存,最后...

    KINGYT
  • 为什么我的进程被kill掉了

    这段代码非常简单,就是先用mmap的方式,为该进程分配10GiB的虚拟内存,然后再用page写的方式,让操作系统为这10GiB虚拟内存,分配对应的物理内存,最后...

    Linux阅码场
  • CPU深夜狂飙,一帮大佬都傻眼了···

    “诸位,突发情况,CPU占用率突然飙升,并且长时间没有降下来的趋势,CPU工厂的阿Q向我们表达了强烈抗议”

    轩辕之风
  • 记一次服务器执行MySQL耗时问题

    导读:本篇记录一次服务器执行MySQL耗时的问题,耗时的问题在于一句SQL执行,耗时超过1000ms,如何解决这个问题?通过这篇文章了解下。

    Criss@陈磊
  • 一条简单的 SQL 执行超过 1000ms,纳尼?

    在测试环境 Docker 容器中,在跨进程调用服务的时候,A 应用通过 Dubbo 调用 B 应用的 RPC 接口,发现 B 应用接口超时错误,接着通过 deb...

    良月柒
  • 记一次服务器执行MySQL耗时问题

    原文:http://www.enmotech.com/web/detail/1/702/1.html (复制链接,打开浏览器即可查看)

    数据和云01
  • 记一次服务器执行MySQL耗时问题

    墨墨导读:本篇记录一次服务器执行MySQL耗时的问题,耗时的问题在于一句SQL执行,耗时超过1000ms,如何解决这个问题?通过这篇文章了解下。

    数据和云
  • 记一次服务器被挖矿木马攻击的经历

    版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/huyuyang6688/article/...

    DannyHoo
  • 无人值守的自动 dump(一)

    Go 项目做的比较大(主要说代码多,参与人多)之后,可能会遇到类似下面这样的问题:

    梦醒人间
  • 一条简单的 SQL 执行超过1000ms,纳尼?

    https://juejin.im/post/5ce906a3e51d455a2f2201dc

    Java技术栈
  • 云数据库MySQL CPU飙升排查流程

    在日常使用MySQL的过程中,会遇到 CPU 使用率过高甚至达到 100% 的情况。CPU飙升会导致数据库无法连接,事务无法提交等一系列问题。本文基于日常问题处...

    苏欣
  • 记一次解决业务系统生产环境宕机问题!

    Zabbix告警生产环境应用shutdown,通过堡垒机登入生产环境,查看应用容器进程,并发现没有该业务应用的相应进程,第一感觉进程在某些条件下被系统杀死了,然...

    Java后端技术
  • Jepsen 测试框架在图数据库 Nebula Graph 中的实践

    在本篇文章中主要介绍图数据库 Nebula Graph 在 Jepsen 这块的实践。

    NebulaGraph
  • 重启大法失效?详述Oracle11g因JDBC bug引发异常Library Cache Lock等待处理事件

    墨墨导读:在Oracle 11g 版本中可能出现由于JDBC bug导致sql绑定变量无法共享,过期游标过多的情况,此时如果发生大量并发业务,很有可能造成异常l...

    数据和云
  • Spark Streaming与Kafka如何保证数据零丢失

    Spark Streaming 是一种构建在 Spark 上的实时计算框架,它扩展了 Spark 处理大规模流式数据的能力。Spark Streaming 的优...

    smartsi
  • 【Pod Terminating原因追踪系列】之 containerd 中被漏掉的 runc 错误信息

    李志宇,腾讯云后台开发工程师,日常负责集群节点和运行时相关的工作,以及 containerd、docker、runc 等运行时组件的定制开发和问题排查。

    腾讯云原生
  • Mysql进阶垫脚石 -- Sql命令的执行状态有哪几种

    每当执行SQL运行缓慢时,我们都会使用 show processlist 查看一下mysql当前进程的执行情况;(如下)

    陈哈哈
  • 一份超详细的Java问题排查工具单

    平时的工作中经常碰到很多疑难问题的处理,在解决问题的同时,有一些工具起到了相当大的作用,在此书写下来,一是作为笔记,可以让自己后续忘记了可快速翻阅,二是分享,希...

    Java团长
  • mysql SQL调优-主库查询比从库还慢的原因

    2、了解到原来应用连接的是主库,随即上主库查看执行计划,如下,可以看到执行计划是不一样的,从库性能没问题,而主库性能有问题,初步可以断定,就是统计信息不准确的原...

    互扯程序

扫码关注云+社区

领取腾讯云代金券