[prev in list] [next in list] [prev in thread] [next in thread] 

List:       log4j-dev
Subject:    [jira] [Updated] (LOG4J2-431) Create MemoryMappedFileAppender
From:       "Claude Mamo (JIRA)" <jira () apache ! org>
Date:       2013-12-24 13:50:52
Message-ID: JIRA.12674239.1381975469792.8251.1387893052322 () arcas
[Download RAW message or body]


     [ https://issues.apache.org/jira/browse/LOG4J2-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel \
]

Claude Mamo updated LOG4J2-431:
-------------------------------

    Attachment: MemoryMappedFileManager.java

> 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
> Priority: Minor
> 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.1.5#6160)

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]