java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid5328.hprof ...
Heap dump file created [529688434 bytes in 4.197 secs]
Exception in thread "EMQ Broker[broker-cnd] Scheduler" java.lang.OutOfMemoryError: Java heap space
at com.xxx.xxx.store.kahadb.disk.journal.DataFileAccessor.readRecord(Unknown Source)
at com.xxx.xxx.store.kahadb.disk.journal.Journal.read(Unknown Source)
at com.xxx.xxx.store.kahadb.plist.PListStoreImpl.getPayload(Unknown Source)
at com.xxx.xxx.store.kahadb.plist.PListImpl$PListIteratorImpl.next(Unknown Source)2014-06-06 14:56:31,169 | WARN | Async error occurred:
java.lang.OutOfMemoryError: Java heap space
at com.xxx.xxx.util.DataByteArrayOutputStream.ensureEnoughBuffer(Unknown Source)
at com.xxx.xxx.util.DataByteArrayOutputStream.write(Unknown Source)
at com.xxx.xxx.openwire.v6.BaseDataStreamMarshaller.looseMarshalByteSequence(Unknown Source)
at com.xxx.xxx.openwire.v6.MessageMarshaller.looseMarshal(Unknown Source)
at com.xxx.xxx.openwire.v6.EMQMessageMarshaller.looseMarshal(Unknown Source)
at com.xxx.xxx.openwire.v6.EMQBytesMessageMarshaller.looseMarshal(Unknown Source)
at com.xxx.xxx.openwire.OpenWireFormat.marshal(Unknown Source)
at com.xxx.xxx.broker.region.cursors.FilePendingMessageCursor.getByteSequence(Unknown Source)
at com.xxx.xxx.broker.region.cursors.FilePendingMessageCursor.tryAddMessageLast(Unknown Source)
at com.xxx.xxx.broker.region.cursors.FilePendingMessageCursor.addMessageLast(Unknown Source)
at com.xxx.xxx.broker.region.Queue.sendMessage(Unknown Source)
at com.xxx.xxx.broker.region.Queue.doMessageSend(Unknown Source)
at com.xxx.xxx.broker.region.Queue.send(Unknown Source)
at com.xxx.xxx.broker.region.AbstractRegion.send(Unknown Source)
at com.xxx.xxx.broker.region.RegionBroker.send(Unknown Source)
at com.xxx.xxx.broker.jmx.ManagedRegionBroker.send(Unknown Source)
at com.xxx.xxx.broker.BrokerFilter.send(Unknown Source)
at com.xxx.xxx.broker.CompositeDestinationBroker.send(Unknown Source)
at com.xxx.xxx.broker.TransactionBroker.send(Unknown Source)
at com.xxx.xxx.broker.BrokerFilter.send(Unknown Source)
at com.xxx.xxx.broker.MutableBrokerFilter.send(Unknown Source)
at com.xxx.xxx.broker.TransportConnection.processMessage(Unknown Source)
at com.xxx.xxx.command.EMQMessage.visit(Unknown Source)
at com.xxx.xxx.broker.TransportConnection.service(Unknown Source)
at com.xxx.xxx.broker.TransportConnection$1.onCommand(Unknown Source)
at com.xxx.xxx.transport.ResponseCorrelator.onCommand(Unknown Source)
at com.xxx.xxx.transport.MutexTransport.onCommand(Unknown Source)
at com.xxx.xxx.transport.vm.VMTransport.iterate(Unknown Source)
at com.xxx.xxx.thread.PooledTaskRunner.runTask(Unknown Source)
at com.xxx.xxx.thread.PooledTaskRunner$1.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at com.xxx.xxx.store.kahadb.plist.PListImpl$PListIteratorImpl.next(Unknown Source)
at com.xxx.xxx.broker.region.cursors.FilePendingMessageCursor$DiskIterator.next(Unknown Source)
at com.xxx.xxx.broker.region.cursors.FilePendingMessageCursor$DiskIterator.next(Unknown Source)
at com.xxx.xxx.broker.region.cursors.FilePendingMessageCursor.next(Unknown Source)
at com.xxx.xxx.broker.region.Queue.doPageInForDispatch(Unknown Source)
at com.xxx.xxx.broker.region.Queue.pageInMessages(Unknown Source)
at com.xxx.xxx.broker.region.Queue.doBrowse(Unknown Source)
at com.xxx.xxx.broker.region.Queue.expireMessages(Unknown Source)
at com.xxx.xxx.broker.region.Queue.access$100(Unknown Source)
at com.xxx.xxx.broker.region.Queue$2.run(Unknown Source)
at com.xxx.xxx.thread.SchedulerTimerTask.run(Unknown Source)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
************************************
【分析】
1、检查是否为游标配置和代码中没有调用clearBody()的问题导致的OOM。
2、消息游标占用正常、从分析工具(ISA -->HeapAnalyzer)看是内存中放置的byteMessage的个数,导致老代被用完了。
3、考虑调整发送byteMessage的代码,产生的byteMessage用完后置空。
4、游标对内存的占用,可以合理控制;发现如果单节点切分byteMessage时,也会导致oom,此时并没有游标在使用,游标仅记录待转发消息的数量。
5、就单节点切分ByteMessage进行分析,发现是因为:com.xxx.xxx.broker.region.Queue.doBrowse触发的问题。因此考虑将队列中的配置策略参数,关于browse的调小。
即:maxBrowsePageSize和maxPageSize配置为1。
6、实际触发是由过期消息检查com.xxx.xxx.broker.region.Queue.expireMessages引起的,可以考虑过期消息检查时,browse大类型消息时,限制browse大小。
===>是否可行?==>只能对某个队列限制,而队列中的消息类型不能进行限制。
注意:消息入队时才占用游标,当消息进入队列后,就不占用游标了。
7、CMS算法会导致碎片。==>
8、默认的【MAX_PAGE_SIZE】与【MAX_BROWSE_PAGE_SIZE】大小关系;
public static final int MAX_PAGE_SIZE = 200;
public static final int MAX_BROWSE_PAGE_SIZE = MAX_PAGE_SIZE * 2;
9、最终解决方法:在代码中判断是否为特定队列,则将其参数maxBrowsePageSize和maxPageSize设置为1,其实关键参数是后者,即【maxPageSize】。
==>maxBrowsePageSize参数用于通过jmx调用Queue的MBean方法,browse时,每次最多显示的消息数量;
==>maxPageSize参数用于从持久化导入消息到内存时,每次的页导入的消息数量。
10、在【com.xxx.xxx.broker.region.Queue.doPageInForDispatch】
/////////begin///////
int toPageIn = Math.min(getMaxPageSize(), messages.size());
/////////end/////////
【温馨提示】
如果您觉得满意,可以选择支持下,您的支持是我最大的动力:
分享到:
相关推荐
事件驱动解析是把文件转换成xml,然后一边读取一边解析,这样就对内存的占用就会很少,可以很好的处理poi出现OOM的问题。 maven添加需要的jar包 <groupId>org.apache.poi <artifactId>poi <version>3.15 ...
如果在Keras内部多次使用同一个Model,例如在不同的数据集上训练同一个模型进而得到结果,会存在内存泄露的问题。在运行几次循环之后,就会报错OOM。 解决方法是在每个代码后面接clear_session()函数,显示的关闭TF...
针对`ViewFlipper`加载多张图片时可能出现的`OOM`问题,我们可以采取以下策略: 1. **图片压缩**:首先,确保图片资源在加载前已经进行了适当的压缩。这可以通过降低图片的分辨率、压缩图片的质量或者使用像`...
在Android开发中,由于内存限制,处理大图时经常会出现“Out Of Memory”(OOM)错误,这会导致应用崩溃。本篇文章将详细讲解如何在Android中加载大图以避免OOM问题,参考自博客《Android加载大图避免OOM》。 1. ...
然而,当帧数过多或者图片尺寸过大时,系统可能无法有效管理这些内存,导致OOM。 为了解决SurfaceView中的帧动画OOM问题,有以下几个关键策略: 1. **优化图片资源**:减小图片的大小和分辨率可以显著降低内存占用...
java jvm 中关于内存溢出分享,举例说明各种情况下可能会出现的oom事故
SpringBoot 中 @Async 默认线程池导致 OOM 问题 在 SpringBoot 中使用 @Async 注解来实现异步操作是一种非常常见的做法,但是如果不小心,可能会导致 OOM(Out of Memory)问题。本文将详细介绍 SpringBoot 中 @...
在Spark运行过程中,内存溢出(OOM)问题可能导致任务失败,影响整个应用程序的效率。本篇文章主要探讨Spark面对OOM问题的解决方法及优化策略。 首先,我们需要了解Spark的内存模型。Spark的Executor内存分为三个...
在Android开发中,由于内存管理机制的特性,开发者经常面临一个棘手的问题——Out Of Memory (OOM)。尤其是在处理图片时,如果不加以控制,大量图片的加载和显示可能导致应用程序崩溃。"Android相册图片解决OOM问题...
当应用程序加载过多的大尺寸图片时,可能会触发"Out Of Memory"(OOM)错误,导致应用崩溃。这个问题在标题“大量加大drawable下图片,导致OOM,使用二次裁剪”中被提及,暗示了解决这一问题的一种策略——二次裁剪...
在Android应用开发中,图片加载是一项关键任务,尤其是在处理大量图片或者进行滑动浏览时,如果处理不当,可能会导致内存溢出(Out Of Memory,简称OOM)。"Android-Universal-Image-Loader-master"是一个非常实用的...
在Android开发中,图片加载是常见的任务,但同时也是导致内存溢出(Out Of Memory, OOM)问题的主要原因之一。特别是当处理大量图片,如在ListView或RecyclerView中滚动时,如果没有正确的图片管理策略,图片加载...
标题“加载本地图片,绝对不会出现OOM.zip”暗示了这个压缩包包含了关于如何在Android应用程序中正确加载本地图片,以避免内存溢出(Out Of Memory,简称OOM)问题的示例代码。在Android开发中,由于有限的内存资源...
问题原因分析:使用ScriptEngine.eval每次都会对脚本进行编译,生成一个新的类,被GroovyClassLoader加载,大量执行计算后,将导致被加载的类数量不断增加,最终OOM。 解决办法:对计算的表达式expression进行预...
OOM全称”Out Of Memory”,即内存溢出。 内存溢出已经是软件开发历史上存在了近40年的“老大难”问题。...如果已经出现OOM,则可以通过dmesg命令查看,CentOS7版本以上支持 -T选项,能将时间戳转成时
在Android开发中,"OOM"(Out Of Memory)是一个常见的问题,尤其是在处理图像资源时。标题"OOM绝对不出现"表明这是一个关于如何避免Android应用程序内存溢出,特别是加载本地图片时的最佳实践。描述中提到“经过...
在Java编程中,"OOM"(Out of Memory)是一个常见的运行时错误,它表示应用程序消耗了超出系统分配的内存资源,导致系统无法再为程序分配新的内存。本篇将通过一个简单的OOM例子来探讨这个问题的发生原因、如何复现...
GridView通过Adapter来绑定数据源,当Adapter中的每一项包含大图时,如果不进行优化,每次滚动都会加载新的图片到内存,导致内存占用持续增加,直至触发OOM。 **LruCache简介** LruCache(Least Recently Used ...
在Android开发中,加载本地图片是一项常见的任务,但如果不妥善处理,可能会引发内存溢出(Out Of Memory,简称OOM)问题。OOM是Android应用中一个常见的运行时异常,尤其是在处理大量图片或者大尺寸图片时,可能...
当应用程序出现Out of Memory (OOM)错误时,通常意味着系统无法分配足够的内存来执行任务,这时就需要借助专业的分析工具来查找问题的根源。MemoryAnalyzer(MAT)是IBM开发的一款强大的JVM堆内存分析工具,它能够...