[ 
https://issues.apache.org/jira/browse/ARTEMIS-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16838551#comment-16838551
 ] 

ASF subversion and git services commented on ARTEMIS-2317:
----------------------------------------------------------

Commit 79465f7f88e32ca477655bb3f7fc6d261511ebae in activemq-artemis's branch 
refs/heads/master from Francesco Nigro
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=79465f7 ]

ARTEMIS-2317 Reuse file buffer wrapper instances to reduce allocations

Page::read is allocating a new ChannelBufferWrapper on each
paged message read: to reduce the allocation rate, it could be
reused until a new wrapped ByteBuffer is created


> Avoid long TTSP caused by Page::read using mmap read
> ----------------------------------------------------
>
>                 Key: ARTEMIS-2317
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-2317
>             Project: ActiveMQ Artemis
>          Issue Type: Improvement
>            Reporter: Francesco Nigro
>            Priority: Major
>             Fix For: 2.7.0
>
>          Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> Page::read is using a readonly mmap to read paged messages: 
> if the OS mapped regions accessed are not into the OS page cache it can cause 
> several major page faults that would lead to suffer very long time to 
> safepoint pauses (it can be seen by enabling 
> -XX:+PrintGCApplicationStoppedTime).
> Such pauses can delay significantly the GC work in a way similar to long 
> Stop-Of-The-World pauses, blocking the broker long enough that any connected 
> client will consider it dead or making the broker itself to suicide by 
> shutdown.
> The original proposal to use mmap read has been used to avoid Page::read to 
> allocate big direct ByteBuffers just to read entirely the paged messages from 
> the filesystem: implementing chunked reading of those files while re-using 
> the read ByteBuffer would allow to reduce the number of syscalls to read the 
> file, avoiding the long time to safepoint pauses too.
> Any OS pauses on JNI (ie NIO FileChannel::read) won't cause any safepoint 
> delay (ie JNI calls are IN a safepoint,not between).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to