[
https://issues.apache.org/jira/browse/ARTEMIS-1996?focusedWorklogId=185207&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-185207
]
ASF GitHub Bot logged work on ARTEMIS-1996:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 15/Jan/19 10:24
Start Date: 15/Jan/19 10:24
Worklog Time Spent: 10m
Work Description: franz1981 commented on issue #2250: ARTEMIS-1996
MappedSequentialFileFactory may cause DirectByteBuffer off-heap memory leaks
URL: https://github.com/apache/activemq-artemis/pull/2250#issuecomment-454285382
@CNNJYB in this case it is wanted: compaction was leaking buffers big as the
file size, while with paging not ie it shouldn't.
The point is that a thread local pool buffer is not a perfect solution, but
is better then no pooling (using heap buffers and FileChannel means that
FileChannel will leak a direct ByteBuffer and will perform an hidden copy) or a
shared (among threads) pool.
We can rethink pooling according to the lifecycle of who perform the page
write: any proposal is welcome to solve it and we can work on a solution
together :)
Just to mention: consider that using a lock-free data-structure could be a
solution too (using a fixed size `AtomicReferenceArray`) and we could bounds
the life-cycle of the pool to the lifecycle of the file factory.
If a factory::close would happen we could just cleanup it...
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 185207)
Time Spent: 1h 20m (was: 1h 10m)
> MappedSequentialFileFactory may cause DirectByteBuffer memory leaks
> -------------------------------------------------------------------
>
> Key: ARTEMIS-1996
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1996
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
> Reporter: tang pu
> Priority: Minor
> Fix For: 2.7.0, 2.6.4
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Because of some customization requirements, the readJournalFile method of
> JournalImpl needs to be calledmultiple times.
> During the stress test, it was found that almost every 5 hours, the Broker
> appeared a Full GC.
> This is the information about the Full GC in the GC log.
> {color:#FF0000}2018-07-25T12:14:07.323+0800: 10089.523: [Full GC
> (System.gc()) 6767M->253M(16G), 8.7138691 secs]{color}
> {color:#FF0000} [Eden: 632.0M(712.0M)->0.0B(816.0M) Survivors: 104.0M->0.0B
> Heap: 6767.6M(16.0G)->253.9M(16.0G)], [Metaspace:
> 36323K->35961K(1083392K)]{color}
> {color:#FF0000} [Times: user=2.56 sys=0.42, real=8.71 secs] {color}
> When the Full GC appears, the thread stack is as follows:
> {color:#FF0000}java.lang.System.gc(System.java:993){color}
> {color:#FF0000}java.nio.Bits.reserveMemory(Bits.java:666){color}
> {color:#FF0000}java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:123){color}
> {color:#FF0000}java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311){color}
> {color:#FF0000}org.apache.activemq.artemis.core.io.mapped.MappedSequentialFileFactory.newBuffer(MappedSequentialFileFactory.java:109){color}
> {color:#FF0000}org.apache.activemq.artemis.core.journal.impl.JournalImpl.readJournalFile(JournalImpl.java:463){color}
> By analyzing the stack, it should be that the JVM's heap memory cannot be
> allocated, causing the JVM to call the System.gc() method.
> In the Broker, MappedSequentialFileFactory caches off-heap memory through
> ThreadLocal. Once the thread is evicted by the CompactExecutor(keepalive is
> 60s) in the Journal, the heap memory is "leaked".
> {color:#FF0000}NIOSequentialFileFactory{color} also has the same problem
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
