[
https://issues.apache.org/jira/browse/LOG4J2-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13722151#comment-13722151
]
Remko Popma commented on LOG4J2-324:
------------------------------------
The drawback of keeping StatusData objects in the ringbuffer is that all
elements are still live during every GC so need to be copied between the Eden
spaces during minor GCs. They may even live just long enough to get promoted to
OldGen and get de-referenced after that. This is not ideal: most GC algorithms
are optimized for either very short-lived or very long-lived objects and don't
like objects that die after promotion to OldGen...
Still, as you mentioned in the mail above, it is very useful to have
_initialization_ logs permanently available even after start-up for inspection
via JMX.
I took a look at FlumePersistentManager. From the way the StatusLogger is used
there, I would think that having many StatusData objects can only be the result
of many exceptions occurring. Is this the case? (I'm thinking that many
exceptions occurring would also have a negative impact on performance, and GC
may not be caused by the StatusData objects...) If this is the case then the
statusLevel idea may not be a solution as I assume you would not want to filter
out errors?
Finally, the StatusData objects themselves are not small. Creating a StatusData
object involves allocating 11 objects and roughly 368 bytes of memory (assuming
it does not contain a Throwable, in which case quite a bit more).
Would it be an idea to "flatten" these objects (perhaps only keep the formatted
message string), or is there a reason to hang on to the StatusData object?
> Potential performance improvement for StatusLogger
> --------------------------------------------------
>
> Key: LOG4J2-324
> URL: https://issues.apache.org/jira/browse/LOG4J2-324
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
> Affects Versions: 2.0-beta8
> Reporter: Remko Popma
>
> From discussion on the mailing list - please feel free to edit this
> description.
> From: Ralph Goers
> To: Log4J Developers List <[email protected]>
> Sent: Wednesday, July 24, 2013 7:57 AM
> Subject: Re: Config additions, WAS: Confused: want low latency: do I need
> BOTH async logger AND async appender??
> I think I just came up with another attribute for the JMX element. I'll have
> to look at the status logger but I believe it is always creating a StatusData
> object and putting it in a ring buffer so they can be printed later. This
> will actually create a lot of objects and will impact performance. So we will
> want to add a statusLevel attribute to the JMX element to specify what the
> level is on the events that should be added to the buffer.
> It was actually kind of cool though as the person doing the performance test
> looked at the JMX stats and even though the status was set to error in the
> configuration they had lots of debug messages in JMX that were quite helpful
> to verify a misconfiguration.
> Ralph
--
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]
