These are separate JVMs, so having a single executor would be of no help. I believe the only way to do what you are asking for is to add configuration so that the asynchronous thread has a semi-random delay when it starts.
Ralph > On Mar 22, 2017, at 7:58 AM, Greg Thomas <greg.d.tho...@gmail.com> wrote: > >> 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 >> --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
