I tested with 100MB file and 1000MB(1GB) file:

base64 /dev/urandom | head -c 100000000 > /tmp/file.100.txt

base64 /dev/urandom | head -c 1000000000 > /tmp/file.1000.txt

For 'less' the memory consumption is the same (since less only loads the chunks you view) but load time and search time is slower in proportion to the size of the file. The 100MB file had a small lag but hardly a problem, but for the bigger file it was quite noticeable.

If, however, you like viewing log files in text editors then your memory consumption will be as your file size and then some (the editor has overhead obviously, and probably cache and stuff). So a 100MB file size is preferable. Obviously performance impact was similar to the one on 'less' (I tried vim, YMMV).

Generally speaking, for file based logging it's really uncommon to see big logs, usually the cap is in the 10's of MB. As for viewing the logs, it's always possible to use standard Linux tooling to easily work with the files, just stick a 'z' before your command i.e. zgrep, zless, zcat, etc. So multiple log files can be concatenated using zcat and then piped to less or whatever you want (even saved to a file if you so wish).

Also anyone familiar with long running processes with logs shouldn't be surprised by log rotations (And the learning cureve for this is way lower than ODL anyway )

The major caveat for this approach is that these commands will take orders of magnitude more to execute (I saw about 4x time to zgrep 9 compressed and 1 raw 100MB log files vs a 1000M raw log file, but YMMV since I'm using random data).

So generally we could enable 20*100MB files, with files after the first two compressed or some such configuration. Then instead of having 2GB of log files we'll have 200MB + whatever compressed 18 files take, which is usually much less than original size since compression works very good on "natural" language, and even better on logs where a lot of information is repeated.

Lots of good thoughts there Mike, thanks. 

I don't think it's possible to configure ODL's existing logging driver to compress some of the rolled-over log files. I also don't think having some sort of other process handle that step would be good. So, cool idea but I'm not sure how we'd do it.

I tested various operations on 100MB, 500MB and 1GB logs. Everything feels instant to a human at 100MB. 500MB are only not-human-instant when opening in vim - few heartbeats of delay. Searching and moving in vim are fine, is is grepping. 1GB takes a good while to open in vim, searching is okay but moving is slow. So I don't think there's much human-impact from using 500MB over 100MB, but there is by the time you get to 1GB.

Yeah I didn't test sizes between 100MB and 1GB but I bet there's some sweet spot which can be found rather easily, but anyway even 500MB as the file size sounds much better.

As for compression I'm not a Log4j2 logrotate configuration expert, but in regular Linux logrotate this feature exists so it might exist in the Log4j2 one as well. However I think this is a bit lower priority so I wouldn't jump through hoops yet.

Yeah, log4j2 can compress on log rotation. If the log rotate pattern has gz as the extension then it does it automatically for you.

Currently it looks like this:

log4j2.appender.rolling.filePattern = ${karaf.data}/log/karaf.log.%i

Setting it to:

log4j2.appender.rolling.filePattern = ${karaf.data}/log/karaf.log.%i.gz 

should do the trick!

mpeterson - Ooo, cool find! Let's try that in a follow-up change.