You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Gary Gregory (JIRA)" <ji...@apache.org> on 2016/03/16 22:36:33 UTC
[jira] [Commented] (LOG4J2-1318) LoggerContext#getLogger causes
heavy GC overhead
[ https://issues.apache.org/jira/browse/LOG4J2-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15198229#comment-15198229 ]
Gary Gregory commented on LOG4J2-1318:
--------------------------------------
What the measurement for? 2.5 vs. 2.4.1? Or 2.4.1 + a patch for [LOG4J2-1180]?
> LoggerContext#getLogger causes heavy GC overhead
> ------------------------------------------------
>
> Key: LOG4J2-1318
> URL: https://issues.apache.org/jira/browse/LOG4J2-1318
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.5
> Reporter: Rodrigo Merino
> Labels: performance
>
> With the changes from LOG4J2-1180, when running performance testing scenarios, we are experiencing some throughput degradations due to an increase in the GC stall time.
> With the changes from LOG4J2-1180, the GC stall went from ~6% to ~11%, having an impact on the application of a reduction of ~32% of the operations throughput. The memory allocation rate both before and after the change is 4GB/s and 12GB/s respectively.
> In both cases, the relevant jvm configuration params were:
> {code}
> -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution -XX:ErrorFile=%MHOME%/logs/err.log -Xloggc:%HOME%/logs/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:+AlwaysPreTouch -Xms2048m -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+UseParNewGC -XX:NewSize=1024m -XX:+UseNUMA
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org