CODEWITHSUNDEEP
log4j2
Rens Groenveld
Rens Groenveld

Reputation: 982

Log4j2 zipping performance

So I have log4j2 setup to log hourly. I know this happens in a background thread. Unfortunately, our products logs a lot, and zips over 500MB hourly. We notice a small hickup at each hour there is being logged, so it looks like the log4j2 background thread takes too much CPU. It is a small hickup, but unfortunately, this already causes internal errors to our product.

Is there any way to improve the performance of the log4j zipping? Could we for example, say to the background thread, that it is only allowed to use a certain percent of the CPU?

edit: I've seen CPU usage going through the roof at the moment it happens, so it is definetely a CPU usage thing.

Upvotes: 2

Views: 1060

Answers (2)

Remko Popma
Remko Popma

Reputation: 36834

The zip format allows a “compressionLevel” configuration attribute. This is something you can experiment with to see if it makes a difference. See the DefaultRolloverStrategy parameters in https://logging.apache.org/log4j/2.x/manual/appenders.html#RollingFileAppender

Another thing to try is simply zip smaller files. You can tell Log4j2 to rollover based on size. You’ll have more smaller log files, but you can post process them offline where it doesn’t disrupt the application.

Upvotes: 2

Uli
Uli

Reputation: 1500

As far as I know there is no built-in way to avoid the high CPU usage on rollover so you have to implement that yourself.

log4j2 is designed to be easily extended. I cannot give you a full solution. But you should have a look at the org.apache.logging.log4j.core.appender.rolling.action.GzCompressAction class which performs the zipping (in case you are using gz). I think it should be possible to implement your own action class and put a delay to the zipping as you like.

Upvotes: 2

Related Questions