记一次OOM排查优化问题

最新推荐文章于 2024-04-21 05:30:00 发布
最新推荐文章于 2024-04-21 05:30:00 发布
阅读量312 收藏
点赞数
分类专栏： Java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_35174296/article/details/104277427
版权
本文记录了一次Java OutOfMemory (OOM) 问题的排查与优化过程，包括理解JVM内存分配、如何在出现OOM时获取内存使用记录、使用jmap和jvisualvm分析内存 dump 文件，以及发现并优化了一个因频繁创建空字符串对象导致的内存浪费问题。作者计划进一步复习JVM内存模型。
摘要由CSDN通过智能技术生成

一、OOM简介

以下为转载的一些知识点，这边主要是记录以下排查过程
1.jvm内存分配不够，电脑内存的大小，不等于java程序能够使用的内存大小。jvm分配的内存大小，可以在JVM启动时，通过配置文件配置。
2.内存利用不当，有两个表现，内存泄漏和内存溢出。

内存泄漏：对象使用完毕后，不能够及时销毁，变成内存垃圾，如果不能够及时清理，内存垃圾越来越多，可用内存越来越少，影响程序的健康运行。虽然java提供GC机制，可以自动进行内存回收，但是逻辑错误，可能导致垃圾堆积过多。如，将太多的局部作用的对象保存为全局对象。
内存溢出：请求分配的内存，比jvm剩余可用内存少，导致程序不能够正确运行，导致崩坏。

二、排查准备

初步计划就是在oom的时候拿到内存的使用记录，然后用工具进行图表分析（图标更直观）
1、在JVM添加参数

-XX:+HeapDumpOnOutOfMemoryError
表示当JVM发生OOM时，自动生成DUMP文件
-XX:HeapDumpPath=/tmp/oom
DUMP文件存放的位置

如果平时想生成dump文件查看一下内存使用情况的话，可以用下面这句话：

jmap -dump:live,format=b,file=myjmapfile.txt 19570

19570是PID&#x

最低0.47元/天 解锁文章
不署名
关注
专栏目录
记一次OOM与内存泄漏排查经历
whiteBearClimb的博客
05-12 383
场景：测试环境有个应用容易爆OOM，导致容器也会不断重启，大佬怀疑是内存泄漏导致的，于是对它进行排查 登陆上对应的服务器，安装Arthas Arthas使用指南 查看仪表盘：dashboard 开始压测前 开始压测后： 堆内存比较满，而且是survivor区和eden区占用率飙升严重，右上角垃圾回收次数不断增加，eden区回收占用时间较长 但是还不能确定是否存在内存泄漏，所谓内存泄漏，也就是内存脱离JVM的控制，无法对泄漏的内存进行回收利用，测试方法是手动GC： jcmd XXX(Java应用的进程号
一次OOM问题排查过程实战记录
01-05
上周运维反馈线上程序出现了OOM，程序日志中的输出为 Exception in thread http-nio-8080-exec-1027 java.lang.OutOfMemoryError: Java heap space Exception in thread http-nio-8080-exec-1031 java.lang.OutOfMemoryError: Java heap space 看线程名称应该是tomcat的nio工作线程，线程在处理程序的时候因为无法在堆中分配更多内存出现了OOM，幸好JVM启动参数配置了-XX:+HeapDumpOnOutOfMemoryE
记一次OOM排查优化实践
mfhfm的博客
07-04 414
工作中遇到了OOM问题需要排查，在此做一下分享，也做一下笔记 这里模拟了工作中的OOM场景，实际代码就不拿出来了，以下是我自己写的代码 定义一个无界队列，频繁往里面加入元素，代码如下，经测试，这是会产生OOM的 /** * @author mengfh * * @version 2020-7-3上午9:15:52 * * @description OOM排查与优化 */ public class OptimizeOOM { public static void main(...
OOM的排查思路
yzx3105的博客
10-26 330
程序的内存不够了，挂掉了Heap dump文件是一个二进制文件，它保存了某一时刻JVM堆中对象使用情况。Heap Dump文件是指定时刻的Java堆栈的快照，是一种镜像文件。Heap Dump一般都包含了一个堆中的Java Objects, Class等基本信息。同时，当你在执行一个转储操作时，往往会触发一次GC，所以你转储得到的文件里包含的信息通常是有效的内容（包含比较少，或没有垃圾对象了）。我们可以这么理解：heap dump记录内存信息的，thread dump是记录CPU信息的。
OOM问题优化问题总结
小猪的专栏
03-17 775
一、原因 1、加载对象过大 2、相对应的资源过多，来不及释放 二、解决 1、在内存引用上做处理（强、软、弱）（ImageLoader 开源框架） 2、获取图片时压缩获取（边界压缩） 3、优先实现缩略图 4、防止同时加载太多，Listview需要的时候才去加载 5、用完马上释放，防止内存泄露， recycle（） 6、尽量不用 setImageBitMap setImage
[OOM] 记一次线上OOM的问题 - ado19861
08-03
在Java开发过程中，内存溢出（Out Of Memory，简称OOM）是常见的问题之一，它会导致应用程序崩溃或性能急剧下降。本文将详细探讨一个线上出现的OOM问题，以及如何通过日志分析、使用Eclipse的Memory Analyzer Tool...
记一次线上 OOM 和性能优化
Java极客技术
01-01 819
大家好，我是鸭血粉丝（大家会亲切的喊我 「阿粉」），是一位喜欢吃鸭血粉丝的程序员，回想起之前线上出现 OOM 的场景，毕竟当时是第一次遇到这么 紧脏 的大事，要好好记录下来。 1 事情回顾 在某次周五，通过 Grafana 监控，发现线上环境突然出现CPU和内存飙升的情况： 但是看到网络输出和输入流量都不是很高，所以网站被别人攻击的概率不高，后来其它服务器的负荷居高不下。 阿粉先 dump 下当...
记一次用jprofilor定位生产环境OOM的经历
行者AI
02-04 262
本文首发于：行者AI 随着平台业务的不断发展，平台曲库数据的不断增加，系统偶尔出现内存溢出的情况。内存溢出相比其它异常而言，通常比较隐晦，一般是伴随着时间慢慢积累而产生的，因此不能仅根据异常产生处来简单定位问题，而要找到问题的根源。所以，有必要知道如何排查系统的内存溢出。本文以一次生产环境下的内存溢出为例，简单讲解如何使用jprofiler定位问题。 1. 问题 突然收到平台出现故障的消息，打开网站首页，发现所有接口均不能正常访问，页面加载失败，如下: 第一时间查看异常日志，发现日志几乎全是如下内容:.
集群容器频繁OOMKilled的排查经历
CallmeMaybe
01-04 1916
发现日志并无异样，也没有相关异常报错信息排查问题细致！注意分析工具的英文解释，每一个英文都得关注（粗心）日常开发引入jar包一定要深入理解最佳实践后才使用，切勿浅尝辄止能用就行一个已经加载的类被卸载的几率是很小的同时被卸载的时间也是不确定的工具方面mat似乎不太好查看已加载类信息，比较侧重不同类加载器加载同一个类导致的重复类问题visualvm也不太好查看已加载类信息arthas不错 功能全面。
Kubernetes Pod OOMKilled诊断
最新发布
Andrew_Chenwq的博客
04-21 974
Container Limit ReachedLimit Overcommit通过kubectl describe pod [name]可以查看pod死亡的具体原因。查看 的最近历史事件，并尝试找出触发 错误的原因，因为只有两个常见原因：
排查OOM的方法
beiduofen2011的专栏
11-14 277
Java命令中设置 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./ import com.example.stu.jvm.User; import java.util.ArrayList; import java.util.List; import java.util.UUID; public class Test3 { public static List<Object> list = new ArrayList&..
OOM排查与定位
hnhygkx的博客
11-05 4085
某Java服务（假设PID=19813）出现了OOM，最常见的原因为： 有可能是内存分配确实过小，而正常业务使用了大量内存 某一个对象被频繁申请，却没有释放，内存不断泄漏，导致内存耗尽 某一个资源被频繁申请，系统资源耗尽，例如：不断创建线程，不断发起网络连接 三种情况： 1 “本身资源不够” 2 “申请资源太多” 3： “资源耗尽”。 更具体的，可以使用以下工具逐一排查。 jps列出所有...
记录一次生产线上JVM_OOM事故排查真实过程（主要分析并定位问题代码）
凹凸曼的博客
12-16 583
文章目录分析准备开始分析 最近几天总出现线上程序莫名其妙登录不上，同事给我说‘没事重启下就好了’（不是大厂），肯定不能总重启啊，这肯定是有问题的。于是就打开日志发现最后报了“java.lang.OutOfMemoryError：Java heap space”。之前也没遇到这种情况，也没有相应的措施。 之前jvm是默认分配的堆大小，于是我就调大了并添加些启动命令方便再次报OOM时观察jvm中堆的状况： -Xms1024m -Xmx1024m -XX:+PrintGCDetails -XX:+PrintGC
OOM（一）：线上排查及解决流程
scofen的博客
11-06 1425
20191105中午12点左右线上报警。 通过gtrace，发现接口响应超时： 通过gtrace查看方法调用链：发现内存溢出。 于是迅速切到普罗米修斯监控： 发现服务从12点01分到04分之间不可用，但之后，在不重启服务的情况下，对外正常提供服务。并且各项指标正常。得出结论，不是堆内存泄露，而是堆内存溢出。 接下来就顺理成章的需要...
高效读取大文件，再也不用担心 OOM 了！
热门推荐
Java极客技术
06-15 1万+
每天早上七点三十，准时推送干货Photo by Luisa Brimble on Unsplash最近阿粉接到一个需求，需要从文件读取数据，然后经过业务处理之后存储到数据库中。这个需求，...
记一次Kettle OOM排查过程，以及想到的四种优化解决方案
攻城狮Kevin
06-24 3975
目录 场景： 排查： 三、最终排查原因 四、解决方案考虑有四种 （1）在kettle中对并行执行的任务增加一个随机时间等待，如下 （2）30个并行任务分3次跑 （3）考虑引入zabbix和zaa监控框架 （4）将部分项目迁移到别的服务器 场景： 公司kettle上有30个子业务，每个业务对应一个项目id（projId），在kettle中设置30个业务并发执行，平时机器都运行健康...
一次OOM问题排查
weixin_34416649的博客
01-18 883
问题描述 用户问题：用户发现自己的服务器CPU在某一时刻陡然升高，但从监控上看，同一时刻的业务量却并不高，客户怀疑是云服务器有问题，希望技术支持团队予以解决。 经过我们的排查，发现cpu的两次间歇飙高是由于客户系统当时发生了OOM（out of memory）的情况，并触发了oom-killer造成的。但客户并不接受这个结论，认为是云服务器的异常导致了c...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值