You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When alloy is terminated, JFR files written to disk by the pyroscope.java file never seem to be cleaned-up. In an extreme scenario when alloy is frequently restarted, like if OOMKilled on kubernetes, then maybe the files gradually accumulate and start filling up the host's disk.
This is making us take a gradual approach to adopting continuous profiling since we're worried about disk pressure on our kubernetes nodes. Not sure how valid of a concern that is, but it would be nice if alloy cleaned-up any of old JFR files, like during start-up
What's wrong?
When alloy is terminated, JFR files written to disk by the
pyroscope.java
file never seem to be cleaned-up. In an extreme scenario when alloy is frequently restarted, like if OOMKilled on kubernetes, then maybe the files gradually accumulate and start filling up the host's disk.This is making us take a gradual approach to adopting continuous profiling since we're worried about disk pressure on our kubernetes nodes. Not sure how valid of a concern that is, but it would be nice if alloy cleaned-up any of old JFR files, like during start-up
Steps to reproduce
/tmp
directory of the java application container. Except after a rare race condition, there should now be two JFR filesSystem information
Ubuntu Linux 22.04.3 x86_64
Software version
v1.4.3
Configuration
https://github.com/grafana/pyroscope/blob/main/examples/grafana-agent-auto-instrumentation/java/kubernetes/grafana-alloy.yaml
Logs
No response
The text was updated successfully, but these errors were encountered: