[
https://issues.apache.org/jira/browse/LOG4J2-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-431:
-------------------------------
Fix Version/s: 2.1
> Create MemoryMappedFileAppender
> -------------------------------
>
> Key: LOG4J2-431
> URL: https://issues.apache.org/jira/browse/LOG4J2-431
> Project: Log4j 2
> Issue Type: New Feature
> Components: Appenders
> Reporter: Remko Popma
> Assignee: Remko Popma
> Priority: Minor
> Fix For: 2.1
>
> Attachments: MemoryMappedFileAppender.java,
> MemoryMappedFileAppenderTest.java, MemoryMappedFileAppenderTest.xml,
> MemoryMappedFileManager.java, MemoryMappedFileManagerTest.java
>
>
> A memory-mapped file appender may have better performance than the ByteBuffer
> + RandomAccessFile combination used by the RandomAccessFileAppender.
> *Drawbacks*
> * The drawback is that the file needs to be pre-allocated and only up to the
> file size can be mapped into memory. When the end of the file is reached the
> appender would need to extend the file and re-map.
> * Remapping is expensive (I think single-digit millisecond-range, need to
> check). For low-latency apps this kind of spike may be unacceptable so
> careful tuning is required.
> * Memory usage: If re-mapping happens too often you lose the performance
> benefits, so the memory-mapped buffer needs to be fairly large, which uses up
> memory.
> * At roll-over and shutdown the file should be truncated to immediately after
> the last written data (otherwise the user is left with a log file that ends
> in garbage).
> *Advantages*
> Measuring on a Solaris box, the difference between flushing to disk (with
> {{RandomAccessFile.write(bytes[])}}) and putting data in a MappedByteBuffer
> is about 20x: around 600ns for a ByteBuffer put and around 12-15 microseconds
> for a RandomAccessFile.write.
> (Of course different hardware and OS may give different results...)
> *Use cases*
> The difference may be most visible if {{immediateFlush}} is set to {{true}},
> which is only recommended if async loggers/appenders are not used. If
> {{immediateFlush=false}}, the large buffer used by RandomAccessFileAppender
> means you won't need to touch disk very often.
> So a MemoryMappedFileAppender is most useful in _synchronous_ logging
> scenarios, where you get the speed of writing to memory but the data is
> available on disk almost immediately. (MMap writes directly to the OS disk
> buffer.)
> In case of a application crash, the OS ensures that all data in the buffer
> will be written to disk. In case of an OS crash the data that was most
> recently added to the buffer may not be written to disk.
> Because by nature this appender would occupy a fair amount of memory, it is
> most suitable for applications running on server-class hardware with lots of
> memory available.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
