logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remko Popma <remko.po...@gmail.com>
Subject Re: [jira] [Commented] (LOG4J2-1297) Document "gc-free" configuration and performance
Date Mon, 18 Apr 2016 12:22:21 GMT
Enabled, except for web apps; for those log4j will be low garbage. 

See the first paragraph of the Configuration section in the manual page. 

Please let me know if this is not clear. (The fact that you asked means this probably needs

Sent from my iPhone

> On 2016/04/18, at 20:18, Mikael Ståldal <mikael.staldal@magine.com> wrote:
> Will garbage-free logging be enabled or disabled by default?
>> On Mon, Apr 18, 2016 at 2:58 AM, Remko Popma (JIRA) <jira@apache.org> wrote:
>>     [ https://issues.apache.org/jira/browse/LOG4J2-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15245018#comment-15245018
>> Remko Popma commented on LOG4J2-1297:
>> -------------------------------------
>> TODO allocate many temporary objects -> allocate temporary objects
>> TODO multi-threaded applications that use synchronous logging may see worse performance:
the lock that was previously only around the IO operation is widened to include the text formatting
and conversion to bytes. -> _synchronous_ logging performance may be worse for multi-threaded
applications in this mode due to synchronization on the shared buffer. If your application
is multi-threaded and logging performance is important, consider using Async Loggers.
>> TODO Caution: Only dates in the predefined formats are garbage-free -> Caution:
Only the predefined date formats are garbage-free
>> TODO "(Note that Log4j may call toString() on message and parameter objects when
garbage-free logging is disabled because system property log4j2.enable.threadlocals is set
to "false".)" -> Log4j may call toString() on message and parameter objects when garbage-free
logging is disabled (when system property log4j2.enable.threadlocals is set to "false".)
>> TODO "made an effort to make logging code garbage-free" -> "made an effort to
make logging garbage-free"
>> > Document "gc-free" configuration and performance
>> > ------------------------------------------------
>> >
>> >                 Key: LOG4J2-1297
>> >                 URL: https://issues.apache.org/jira/browse/LOG4J2-1297
>> >             Project: Log4j 2
>> >          Issue Type: New Feature
>> >          Components: Documentation
>> >    Affects Versions: 2.5
>> >            Reporter: Remko Popma
>> >            Assignee: Remko Popma
>> >             Fix For: 2.6
>> >
>> >         Attachments: log4j-2.5-FlightRecording.png, log4j-2.6-FlightRecording.png
>> >
>> >
>> > Update the site with a description of which configurations are GC-free (i.e.,
that don't create temporary objects in steady running state).
>> > Currently that means
>> > * Loggers are all asynchronous (Log4jContextSelector is set to org.apache.logging.log4j.core.async.AsyncLoggerContextSelector).
>> > * The configuration does not contain a <Properties> section.
>> > * The "steady-state" appenders are either RandomAccessFile or RollingRandomAccessFile
Appenders (logging to any other appender will cause temporary objects to be created - including
>> > * The Layout is a PatternLayout that uses one of the pre-defined date formats,
does not have any regular expression replacements, and does not have lookups (TODO: may need
to restrict this further).
>> > * The thread name is cached (this is the [default|https://issues.apache.org/jira/browse/LOG4J2-467]).
Running with -DAsyncLogger.ThreadNameStrategy=UNCACHED will create garbage.
>> > * In user code, when logging a parameterized message, the number of parameters
is no more than ... (TBD pending discussion in LOG4J2-1278).
>> > * In user code, when logging a parameterized message, parameters of primitive
type are boxed in a reused StringBuilder (Log4j provides a utility to make this relatively
>> > Even with the above restrictions, Log4j may occasionally create garbage:
>> > * Initially StringBuilders are presized to 128 characters. They may grow for
larger messages (contributing to garbage in Old Gen). If  the StringBuilder grows beyond 512
characters it is trimmed back to 512 characters to prevent memory leaks from excessively long
messages. (TODO: the resizing algorithm is {{size = value.length * 2 + 2}}, so a better cutoff
value is 518.)
>> > * Messages containing {{"$\{"}} will be converted to a String and StrSubstitutor
will be used to replace occurences of variables with their matching values. Multiple temporary
objects are created during this process.
>> > Furthermore, we need to explain that some of this functionality depends on ThreadLocals
and so is disabled by default in web applications to prevent memory leaks. The page should
also explain how to manually switch off the use of ThreadLocals.
>> > Finally, the page should show a performance test comparison similar to the [performance
section|http://logging.apache.org/log4j/2.x/manual/async.html#Performance] on the Async Loggers
page. I'm thinking a comparison between Logback, Log4j-1, Log4j-2.0, Log4j-2.6 "classic" and
Log4j-2.6 "gc-free" would be ideal.
>> --
>> 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
> -- 
> Mikael Ståldal
> Senior software developer 
> Magine TV
> mikael.staldal@magine.com    
> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com             
> Privileged and/or Confidential Information may be contained in this message. If you are
not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not copy or deliver
this message to anyone. In such case, 
> you should destroy this message and kindly notify the sender by reply email.   

View raw message