[
https://issues.apache.org/jira/browse/LOG4J2-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13723705#comment-13723705
]
Remko Popma commented on LOG4J2-327:
------------------------------------
Thanks for the report.
I recognize a few issues from your description. Was the excessive memory usage
with AsyncLoggers?
LOG4J2-304 fixes a memory leak in the AsyncLoggers ringbuffer.
The IllegalArgumentExeption with FastRollingFile I believe may be related to
LOG4J2-311.
These two issues have been fixed in trunk. Could you give that a try? (How to
build: http://logging.apache.org/log4j/2.0/build.html)
This may not be the whole answer though... Especially the issue where you
mention a 372 KB string that is not GC-ed, containing concatenated log
messages, that sounds very strange. To double-check, that problem occurred with
beta8, using only a RollingFileAppender and ConsoleAppender, correct? Were you
using AsyncLoggers?
It is hard to know where to start with this issue. Would it be possible for you
to create a program that reproduces this issue?
> Log4j 2 drastical performance loss
> ----------------------------------
>
> Key: LOG4J2-327
> URL: https://issues.apache.org/jira/browse/LOG4J2-327
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Core, Layouts
> Affects Versions: 2.0-beta7, 2.0-beta8
> Environment: Windows 7 64 bit, JDk 1.6.0_43
> Reporter: Sebastian Oerding
> Priority: Blocker
> Labels: performance
>
> Hello,
> we encountered a severe performance loss with log4j 2. Unfortunately we have
> no exact error description such as a stacktrace but I'll give it may best
> shot.
> We are developing an application working with mass data. During the
> development we are running tests such as importing 15,000 files via FTP or
> creating 500,000 business objects and workiong with them.
> Switching from log4j 1.2.17 to log4j 2 we ran into really severe performance
> issues.
> With the beta7 we even get an OutOfMemoryError. Using a profiler we see that
> there was a huge amount of string objects (that were log messages according
> to a control sample).
> Switching to the beta8 the profiler shows there are only 10 % of the string
> objects left that we had before but it still was a big number. Especially the
> strings live for a really long time (> 100 generations).
> Using the RollingFileAppender and ConsoleAppender, (not a FlumeAppender for
> which a memory has been fixed in beta8) and default garbage collection we had
> the following behaviour with beta8:
> Starting the application (each time exactly the same test scenario) the
> machine fastly reaches the memory limit given for the JVM. Afterwards
> periodically garbage collection is invoked, causing a long "Stop the World
> Phase"
> (8 minutes in another scenario), freeing memory down a "base level" and the
> application continues until the memory is full again. The base level remains
> the same for next invocations of the garbage collection.
> This may relate to tickets: https://issues.apache.org/jira/browse/LOG4J2-323,
> https://issues.apache.org/jira/browse/LOG4J2-322,
> https://issues.apache.org/jira/browse/LOG4J2-304.
> Furthermore when looking into one string object being not GCed (372 KB) I
> noticed that it contained a lot of log messages being concatenated. The
> application contains no log statement that logs such a big message.
> Looking at the string towards the end I found even complete log events
> including the log level and so on not only the message. This feels being
> related to https://issues.apache.org/jira/browse/LOG4J2-290, somehow log
> events /
> strings get concatenated / corrupted.
> Maybe it is even a problem with the ParameterizedMessage which we use a lot
> of.
> Switching to the AsyncAppender (FastRollingFile) asynhronously the
> application performs better than with the RollingFile but still bad. Running
> the same scenario with the FastRollingFile "immediateFlush" and "append"
> parameters ommitted in the configuration the FastRollingFile crashed due to a
> IllegalArgumentExeption in class ByteBuffer (stacktrace is lost).
> The blocker priority may be at bit extremen but currently we are thinking of
> going back to log4j 1.2.17, throwing away several days of work and requiring
> a few days for adjusting our code. Hence this is a blocker for us as we could
> not release our software in the current state.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
