[ 
https://issues.apache.org/jira/browse/LOG4J2-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13722131#comment-13722131
 ] 

Ralph Goers commented on LOG4J2-324:
------------------------------------

What was observed was that the number of minor GCs increased a lot during the 
test. My guess is that because FlumePersistentManager is logging debug events 
that lots of these are being created and then released as they expire. However, 
I am still looking into this and the GC increase might be due to something else.
                
> 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]

Reply via email to