解决JVM进程被系统杀掉问题

这篇具有很好参考价值的文章主要介绍了解决JVM进程被系统杀掉问题。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

背景

服务A在测试环境,隔几个小时接口就无法访问。登录机器查看,发现进程已经没了。大致猜想是进程使用的内存或CPU资源使用太多,导致被系统kill。

问题定位

使用dmesg命令查看进程被kill的详情。

> dmesg --time-format iso
2024-03-05T02:45:48,770989+0000 pool-2-thread-6 invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
2024-03-05T02:45:48,779128+0000 CPU: 0 PID: 838 Comm: pool-2-thread-6 Not tainted 5.10.184-175.749.amzn2.x86_64 #1
2024-03-05T02:45:48,911347+0000 Mem-Info:
2024-03-05T02:45:48,914582+0000 active_anon:83 inactive_anon:455069 isolated_anon:0
                                 active_file:71 inactive_file:1104 isolated_file:32
                                 unevictable:0 dirty:0 writeback:0
                                 slab_reclaimable:4982 slab_unreclaimable:6781
                                 mapped:555 shmem:118 pagetables:2540 bounce:0
                                 free:13097 free_pcp:394 free_cma:0
2024-03-05T02:45:48,939533+0000 Node 0 active_anon:332kB inactive_anon:1820276kB active_file:1748kB inactive_file:1908kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:2220kB dirty:0kB writeback:0kB shmem:472kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB kernel_stack:8048kB all_unreclaimable? no
2024-03-05T02:45:48,958593+0000 Node 0 DMA free:7924kB min:364kB low:452kB high:540kB reserved_highatomic:0KB active_anon:0kB inactive_anon:7688kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15992kB managed:15908kB mlocked:0kB pagetables:16kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
2024-03-05T02:45:48,977738+0000 lowmem_reserve[]: 0 1891 1891 1891
2024-03-05T02:45:48,981797+0000 Node 0 DMA32 free:44716kB min:44688kB low:55860kB high:67032kB reserved_highatomic:0KB active_anon:332kB inactive_anon:1812588kB active_file:1748kB inactive_file:1840kB unevictable:0kB writepending:0kB present:2041768kB managed:1954608kB mlocked:0kB pagetables:10144kB bounce:0kB free_pcp:2084kB local_pcp:1164kB free_cma:0kB
2024-03-05T02:45:49,003571+0000 lowmem_reserve[]: 0 0 0 0
2024-03-05T02:45:49,007346+0000 Node 0 DMA: 1*4kB (U) 2*8kB (UM) 4*16kB (UME) 5*32kB (UME) 4*64kB (UME) 4*128kB (UME) 3*256kB (UME) 2*512kB (UE) 3*1024kB (UE) 1*2048kB (U) 0*4096kB = 7924kB
2024-03-05T02:45:49,020018+0000 Node 0 DMA32: 223*4kB (UME) 118*8kB (UE) 180*16kB (UME) 300*32kB (UME) 189*64kB (UME) 31*128kB (UM) 4*256kB (UM) 0*512kB 1*1024kB (M) 4*2048kB (M) 1*4096kB (M) = 44716kB
2024-03-05T02:45:49,032871+0000 Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB
2024-03-05T02:45:49,040653+0000 Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
2024-03-05T02:45:49,047994+0000 1180 total pagecache pages
2024-03-05T02:45:49,051655+0000 0 pages in swap cache
2024-03-05T02:45:49,055150+0000 Swap cache stats: add 0, delete 0, find 0/0
2024-03-05T02:45:49,059720+0000 Free swap  = 0kB
2024-03-05T02:45:49,062834+0000 Total swap = 0kB
2024-03-05T02:45:49,065939+0000 514440 pages RAM
2024-03-05T02:45:49,069266+0000 0 pages HighMem/MovableOnly
2024-03-05T02:45:49,072870+0000 21811 pages reserved
2024-03-05T02:45:49,076104+0000 0 pages hwpoisoned
2024-03-05T02:45:49,079323+0000 Tasks state (memory values in pages):
2024-03-05T02:45:49,083269+0000 [  pid  ]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name
2024-03-05T02:45:49,322324+0000 [   2396]     0  2396     6972       52   102400        0             0 atd
2024-03-05T02:45:49,329382+0000 [   2401]     0  2401     6171      158    94208        0             0 crond
2024-03-05T02:45:49,336441+0000 [   2421]     0  2421     2640       31    69632        0             0 agetty
2024-03-05T02:45:49,343630+0000 [   2423]     0  2423    30328       32    73728        0             0 agetty
2024-03-05T02:45:49,350830+0000 [   2471]     0  2471   180962     1854   147456        0             0 ssm-agent-worke
2024-03-05T02:45:49,358399+0000 [   2518]     0  2518     1068       27    57344        0             0 acpid
2024-03-05T02:45:49,374968+0000 [   4629]  1000  4629  1828472   445489  5488640        0             0 java
2024-03-05T02:45:49,404273+0000 [   4196]  1001  4196    31300      340    86016        0             0 bash
2024-03-05T02:45:49,413123+0000 [   8991]    89  8991    22598      254   204800        0             0 pickup
2024-03-05T02:45:49,439185+0000 oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=java,pid=4629,uid=1000
2024-03-05T02:45:49,454767+0000 Out of memory: Killed process 4629 (java) total-vm:7313888kB, anon-rss:1781956kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:5360kB oom_score_adj:0

在日志最后看到jvm进程被kill,原因是使用了7G的虚拟内存和1.7G的真实内存。而机器的内存是514440 pages * 4K ≈ 2G。

为什么JVM会使用1.7G内存?

JVM配置是-Xmx1500m -XX:MaxMetaspaceSize=256M,所以加起来用了1.7G,导致系统内存不足。处理的方案是:

第一步,先将-Xmx1500m改成-Xmx1024m,避免进程被jvm杀死。

然后,系统能占用这么多内存,一定是发生了内存泄露。在系统OOM时,尝试把堆内存dump出来,在JVM启动命令加上 -XX:HeapDumpPath=/tmp/java_heapdump.hprof 参数。

分析堆内存

得到堆文件后,通过MAT(Memory Analyzer Tool)进行分析内存使用情况。下载地址是:Eclipse Memory Analyzer Open Source Project | The Eclipse Foundation

注意事项
文档里写了“The minimum Java version required to run the stand-alone version of Memory Analyzer is Java 17. See JRE/JDK Sources.”,也就是运行的最低JDK版本是17.

需要下载JDK17后,在MemoryAnalyzer.ini配置文件里加上JDK的路径,如下所示:
-vm
E:\\jdks\\jdk-17\\bin

另外,内存解析比较耗内存,最好给MAT分配更多的内存,在配置里设置:-Xmx4096m

MAT提供了内存泄露的分析能力,在Overview→Reports→Leak Suspects就能看到分析报告。

解决JVM进程被系统杀掉问题,故障处理,jvm,linux,服务器

Leak Suspects

报告里给出了3个可能的泄露点,以及对象各自占用的内存大小:

解决JVM进程被系统杀掉问题,故障处理,jvm,linux,服务器

可以看到,a+b+c占用已经将近900M,我们再展开看看是什么对象占用了内存。

解决JVM进程被系统杀掉问题,故障处理,jvm,linux,服务器

描述里说了一个com.microsoft.cognitiveservices.speech.SpeechSynthesizer就占用了400M内存,大部分内存都是放在Object[]数组里。

接下来我们要找到占用最大内存的SpeechSynthesizer对象,看里面那个属性造成内存泄露。

Dominator Tree

Dominator Tree能列出大对象和它们内部的对象路径。

解决JVM进程被系统杀掉问题,故障处理,jvm,linux,服务器

从图中就能看到,第一个SpeechSynthesizer对象占用了400M,并且是VisemeReceived属性里的eventHandlerClients数组,包含了823个对象。数组里的元素是Text2SpeechMicrosoft类里的一个lambda对象,每个对象占用约1M。

至此,问题就很好定位了,找到eventHandlerClients数组追加元素的地方,看是否有异常。

解决JVM进程被系统杀掉问题,故障处理,jvm,linux,服务器

问题的原因

泄露的地方是,我们用到了微软的文本转语音功能,要拿到Viseme信息,这个信息要通过回调接口获得,所以需要注册一个回调函数。

speechSynthesizer.VisemeReceived.addEventListener(visemeEventHandler);

原来speechSynthesizer对象每次都会创建,由于创建比较耗时,改用了预创建一批放入线程池的方式。这就导致speechSynthesizer对象会被复用,那么调用addEventListener(visemeEventHandler),而不删掉的话,就会越来越多。解决的方案是加上removeEventListener(visemeEventHandler)方法。

总结

遇到问题的时候,通过dmesg命令确定进程是被系统kill。然后,用 -XX:HeapDumpPath命令拿到堆信息。最后,通过MAT工具分析内存泄露的地方。文章来源地址https://www.toymoban.com/news/detail-839839.html

到了这里,关于解决JVM进程被系统杀掉问题的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • JVM:全面理解线上服务器内存溢出(OOM)问题处理方案(一)

    前段时间生产上遇到了OOM问题,导致服务出现了短时间的不可用,还好处理及时,否则也将酿成大祸。OOM问题也是生产中比较重要的问题,所以本期我们针对OOM问题特别讲解,结合理论与实际案例来带大家彻底攻克OOM问题处理。 要解决问题,我们首先要清楚问题产生的原因。

    2024年02月12日
    浏览(44)
  • 大数据之LibrA数据库系统告警处理(ALM-12007 进程故障)

    告警解释 进程健康检查模块按5秒周期检测进程状态。当进程健康检查模块连续三次检测到进程连接状态为故障时,产生该告警。 当进程连接正常时,告警恢复。 告警属性 告警ID 告警级别 可自动清除 12007 严重 是 告警参数 参数名称 参数含义 ServiceName 产生告警的服务名称。

    2024年02月06日
    浏览(39)
  • Java线上故障排查(CPU、磁盘、内存、网络、GC)+JVM性能调优监控工具+JVM常用参数和命令

    根据服务部署和项目架构,从如下几个方面排查: (1)运用服务器:排查内存,cpu,请求数等; (2)文件图片服务器:排查内存,cpu,请求数等; (3)计时器服务器:排查内存,cpu,请求数等; (4)redis服务器:排查内存,cpu,连接数等; (5)db服务器:排查内存,cpu,连接数

    2024年02月07日
    浏览(67)
  • JVM进程缓存Caffeine

    导入坐标: 写一个配置类: 注入bean // 取数据,包含两个参数: // 参数一:缓存的key // 参数二:Lambda表达式,表达式参数就是缓存的key,方法体是查询数据库的逻辑 // 优先根据key查询JVM缓存,如果未命中,则执行参数二的Lambda表达式 增删改 都要清除缓存

    2024年02月11日
    浏览(53)
  • Redis进阶 - JVM进程缓存

    原文首更地址,阅读效果更佳! Redis进阶 - JVM进程缓存 | CoderMast编程桅杆 https://www.codermast.com/database/redis/redis-advance-jvm-process-cache.html 传统缓存的问题 传统的缓存策略一般是请求到达 Tomcat 后,先查询 Redis ,如果未命中则查询数据库,存在下面的问题: 请求要经过 Tomcat 处理

    2024年02月11日
    浏览(39)
  • 【Flink】关于jvm元空间溢出,mysql binlog冲突的问题解决

    Caused by: io.debezium.DebeziumException: A slave with the same server_uuid/server_id as this slave has connected to the master; the first event ‘’ at 4, the last event read from ‘/home/mysql/log/mysql/mysql-bin.003630’ at 62726118, the last byte read from ‘/home/mysql/log/mysql/mysql-bin.003630’ at 62726118. Error code: 1236; SQLSTATE: HY000. 网上

    2024年02月10日
    浏览(40)
  • 【Jvm】性能调优(拓展)Jprofiler如何监控和解决死锁、内存泄露问题

    Jprofilers是针对Java开发的 性能分析工具(免费试用10天) , 可以对Java程序的 内存,CPU,线程,GC,锁 等进行监控和分析 , 本人IDEA版本是 2020.2.2 ,选择的Jprofiler版本是 12.0 (早期的版本是纯英文的, 12.0支持中文 ,安装主要考虑是否与IDEA插件兼容即可) 进入Jprofiler官网下载 - Jprofiler 版本这

    2024年02月19日
    浏览(48)
  • 【Gradle】Gradle之JVM进程详解

    个人主页 :金鳞踏雨 个人简介 :大家好,我是 金鳞 ,一个初出茅庐的Java小白 目前状况 :22届普通本科毕业生,几经波折了,现在任职于一家国内大型知名日化公司,从事Java开发工作 我的博客 :这里是CSDN,是我学习技术,总结知识的地方。希望和各位大佬交流,共同进

    2024年02月16日
    浏览(30)
  • 线程和进程的区别(从JVM角度出发)

    线程具有许多传统进程所具有的特征,故又称为轻型进程(Light—Weight Process)或进程元;而把传统的进程称为重型进程(Heavy—Weight Process),它相当于只有一个线程的任务。在引入了线程的操作系统中,通常一个进程都有若干个线程,至少包含一个线程。 根本区别:进程是操作系

    2024年01月22日
    浏览(92)
  • JVM工具-1. jps:虚拟机进程状态工具

    jps(JVM Process Status Tool):虚拟机进程状态工具,可以列出正在运行的虚拟机进程,并显示虚拟机执行主类(Main Class,main()函数所在的类)的名称,以及这些进程的本地虚拟机的唯一ID(LVMID,Local Vitual Machine Identifier),它是使用频率最高的JDK命令行工具,因为其他JDK工具大多需要

    2024年02月11日
    浏览(41)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包