[jira] [Work logged] (ARTEMIS-1996) MappedSequentialFileFactory may cause DirectByteBuffer memory leaks

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ARTEMIS-1996?focusedWorklogId=184763&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-184763 ]

ASF GitHub Bot logged work on ARTEMIS-1996:
-------------------------------------------

                Author: ASF GitHub Bot
            Created on: 14/Jan/19 11:37
            Start Date: 14/Jan/19 11:37
    Worklog Time Spent: 10m 
      Work Description: CNNJYB commented on issue #2250: ARTEMIS-1996 MappedSequentialFileFactory may cause DirectByteBuffer off-heap memory leaks
URL: https://github.com/apache/activemq-artemis/pull/2250#issuecomment-453976444
 
 
   @franz1981 Why not include the same optimizations while reading and writing the page ?
 
----------------------------------------------------------------
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:
users@infra.apache.org


Issue Time Tracking
-------------------

            Worklog Id:     (was: 184763)
            Time Spent: 10m
    Remaining Estimate: 0h

> 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: 10m
>  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)