[
https://issues.apache.org/jira/browse/LOG4J2-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak closed LOG4J2-2606.
--------------------------------
> Asynchronous logging when the queue is full results heavy CPU load
> ------------------------------------------------------------------
>
> Key: LOG4J2-2606
> URL: https://issues.apache.org/jira/browse/LOG4J2-2606
> Project: Log4j 2
> Issue Type: Bug
> Affects Versions: 2.11.2
> Reporter: Carter Kozak
> Assignee: Carter Kozak
> Priority: Major
> Fix For: 2.12.0
>
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> I've encountered unexpected performance characteristics when the asynchronous
> logging queue is full, resulting in the application becoming unavailable for
> an extended period of time.
> I think EventRoute.ENQUEUE is using a spin lock (or similar construct). When
> many threads attempt to log at a higher rate than we can drain the queue,
> logging throughput drops significantly while CPU utilization skyrockets
> causing instability across the system.
> I can reproduce this in a benchmark (I will clean it up and push when I have
> a moment) where I get the following results:
> Setup:
> Root logger has a random access file appender with immediateFlush disabled
> AsyncLoggerContextSelector enabled for completely asynchronous logging
> 1 thread logging, any queue full policy: ~1,400k events/second, 150% CPU
> 32 threads logging, default policy (EventRoute.ENQUEUE, default policy):
> 300k-400k events/second. 930% CPU load
> 32 threads logging, custom policy using EventRoute.SYNCHRONOUS: 1,200k
> events/second. 350% CPU load
> Using the synchronous policy results in ~1/3 the CPU load and 3-4x throughput
> when the system is loaded to the point that the logging queue is filled.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
