franz1981 commented on a change in pull request #2633: ARTEMIS-2317 Avoid long
TTSP caused by Page::read using mmap read
URL: https://github.com/apache/activemq-artemis/pull/2633#discussion_r279620489
##########
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/paging/impl/Page.java
##########
@@ -120,105 +110,133 @@ public void setLiveCache(LivePageCache pageCache) {
throw ActiveMQMessageBundle.BUNDLE.invalidPageIO();
}
- final List<PagedMessage> messages = new ArrayList<>();
-
size.lazySet((int) file.size());
- if (this.canBeMapped) {
- readFromMapped(storage, messages);
Review comment:
I forgot to answer you on
> Good job. By the way, How did you find the issue?
Using clustering we have measured such long time to safepoint pauses that
was causing the broker to become unresponsive so I've investigated on them
using an approach similar to
https://www.mail-archive.com/[email protected]/msg01122.html.
I have found that `MappedByteBuffer::get` was making the CPU to get
descheduled for several seconds, making the whole JVM to freeze.
The filesystem used was XFS so the reason behind such behaviour wasn't
dependent by any ext4 journalling daemon, but due to major page faults + I/O
activity to fill the OS page cache.
As I've said: assuming infinite RAM and the fastest disk ever with XFS, this
issue is very unlikely to happen, but if it happens, there are no way to solve
it with OS/env tunings and is very stealthy too.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
