[
https://issues.apache.org/jira/browse/LOG4J2-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma closed LOG4J2-327.
------------------------------
Thanks for the feedback, Sebastian.
Closing 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
> Fix For: 2.0-beta9
>
>
> 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: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
