>One common issue we have with that framework (and I assume we can have the
>same with log4j2) is that all of our JVMs (we can have more than 50 JVMs on
>the same server in production) roll their file at midnight.
>
>When this happens, the system became often not usable for a few seconds
>because of the simultaneous zipping of all the rolled files that overload
>the CPU (although zipping is done in a specific background thread).

ISTR that with the most recent versions of log4j, these threads are in a
thread pool so that they are properly shutdown at the right time. I wonder
if it's possible (or could be possible) to somehow inject a thread pool in
to log4j for this rollover, so that for you use case you could inject a
single thread executor, so only one thread is ever compressing at a time.

Just a thought, anyway,

Greg

On 22 March 2017 at 13:47, Anthony Maire <maire.anth...@gmail.com> wrote:

> Hi
>
> We are currently using another logging framework in production, but I'm
> pushing to change it for log4j2.
>
> One common issue we have with that framework (and I assume we can have the
> same with log4j2) is that all of our JVMs (we can have more than 50 JVMs on
> the same server in production) roll their file at midnight.
>
> When this happens, the system became often not usable for a few seconds
> because of the simultaneous zipping of all the rolled files that overload
> the CPU (although zipping is done in a specific background thread). To
> reduce this effect, we are combining a time based rolling policy with a
> sized based policy to zip smaller files, but this is not enough to make the
> system fully responsive at midnight.
>
> A pretty cool feature for us to avoid this issue is to have the possibility
> when a rolling is triggered because of a time based policy to change file
> immediately, but to wait for a random amount of time (within a configurable
> limit) before starting the compression. This random delay should help a lot
> to avoid contention on CPU cycles.
>
> Does log4j2 have something to solve this kind of issue ? If not, would you
> accept a pull request for this (I will open a Jira if needed) ?
>
> Regards,
> Anthony
>

Reply via email to