jdk.Checkpoint

[Michael Bien]

replies inline

On 23.02.20 02:29, Erik Gahlin wrote:
>>> Do you see a problem with the additional 8 MB of data, or are you just curious?
>> I was curious for the most part. With the default profile i probably wouldn't have even noticed it. But i came from the perspective of evaluating if JFR could be used as logging replacement. The good news is that it is static uptime footprint and it doesn't increase with load which is great. But on the other hand you could put a lot of log lines into ~8MB daily.
>>
>> Maybe it would be possible to consider making the flush/checkpoint interval configurable for use cases where the realtime nature of event streaming is less important.
> There is an undocumented command line flag that can be used to increase the interval. It was put in there as a workaround, if users would run into issues compared to JDK 13. Plan is to remove the flag once we know there are no issues.
>
> This is why I am curious about your use case.

What I did is to add a page load event to a custom build of apache 
roller to check if anybody is reading my weblog. It could just be 
printed to a log file but the nice benefit of having it in the JFR 
records is that i get graphs for free, by just opening it in 
JVisualVM/MissionControl or streaming it into a few lines of JavaFX with 
the new api. Correlating it with GC events/network/CPU load etc is also 
super easy that way.


>
> We didn’t expect anybody to notice, especially not before JDK 14 was released :)

If i would get 8 MB of page load events per day my raspberry pi would be 
on fire - but it wasn't - so it had to be something else :)


>
> There are other things than can be done, for instance, only write the file header checkpoint if a JMX client has actually connected and requested a stream.
>
> Anyway, this is good feedback.

no problem


>> Or maybe this is the wrong approach and I should only view the JFR records as log buffer and use streaming to extract what is needed for compact storage.
> The file format is pretty compact, so it is unfortunate that the checkpoint event eats up so much space in your scenario. You could try to zip the recording file. If the compression algorithm is good, it should be able to reduce the 8 MB significantly due to all the redundancy.

Yeah it compresses really well - at least 5x file size reduction. So the 
~3 GB of check points per year should end up much smaller.


>
> Thanks
> Erik
>

best regards

michael