¿Cómo obtener una grabación rodante en disco, con una antigüedad máxima ?
Cuando algo sale mal en mi servidor, quiero poder volcar la información de perfiles de las horas anteriores y analizarla para saber qué salió mal.
Entonces, en otras palabras, quería que el JDK guardara las grabaciones continuamente en el disco, pero eliminara los archivos/grabaciones más antiguos de modo que la cantidad total permaneciera por debajo de cierto umbral (antigüedad o tamaño).
Para ello, estas son las opciones que tengo para la versión Oracle JDK 1.8.0_144 :
-XX:+UnlockCommercialFeatures -XX:+FlightRecorder -XX:StartFlightRecording name=<foo-bar> -XX:FlightRecorderOptions defaultrecording=true // what does this do even? disk=true maxage=1h // this is what I thought would solve my problem! repository=<path-to-where-I-want-the-recording> maxchunksize=5M Hubiera pensado que configurar maxage=1h solo mantendría la última hora de grabación en el disco. ¡Pero no! Ha pasado 1 día y los archivos no están limitados.
Al mismo tiempo maxchunksize parece funcionar. Los diversos archivos .jfr tienen aproximadamente 5M. De los cuales hay muchos expedientes de este tipo, ya que no se está aplicando el límite de edad.
¿Qué estoy haciendo mal?
Creo que el problema es que está iniciando dos grabaciones, una con -XX:StartFlightRecording y otra con -XX:FlightRecorderOptions=defaultrecording=true .
El que tiene -XX:StartFlightRecording es ilimitado. Creo que la siguiente sería la opción adecuada para Oracle JDK 1.8.0_144 y su caso de uso:
-XX:+UnlockCommercialFeatures -XX:FlightRecorderOptions=repository=<path> -XX:StartFlightRecording=maxage=1h,name=<name> -XX:+UnlockCommercialFeatures porque JFR es una función comercial en Oracle JDK 8. Desde JDK 11, ya no es necesario.
-XX:+FlightRecorder no es necesario para JDK 8u40 o posterior. Los búferes JFR ahora están configurados cuando se inicia la primera grabación, no cuando se inicia la JVM.
-XX:FlightRecorderOptions=defaultrecording=true hace muchas cosas, principalmente por razones históricas, pero solo es necesario cuando se realizan grabaciones en memoria. A partir de JDK 9, la opción nunca se necesita y se eliminó.
-XX:FlightRecorderOptions=disk=true,maxage=1h no es necesario si se -XX:StartFlightRecording , que es la forma recomendada de iniciar JFR.
A menos que tenga un problema, mantendría el maxchunksize en el valor predeterminado (12 MB). Es el tamaño de archivos fragmentados para el que JFR ha sido optimizado y probado.
Acepto la respuesta de Kire Haglin .
Agregando un poco más de valor para lo que funcionó para mí en este JDK:
-XX:+UnlockCommercialFeatures -XX:StartFlightRecording name=<foo-bar> maxage=12h dumponexit=true -XX:FlightRecorderOptions dumponexitpath=<path-to-file>.jfr disk=true repository=<some-folder-path> Observe los parámetros adicionales dumponexit y dumponexitpath , que no están presentes en mi pregunta original. Terminé necesitando también esos.
Después de prueba y error, parece que dumponexit debe existir dentro del argumento XX:StartFlightRecording y dumponexitpath en el argumento FlightRecorderOptions . Ningún otro arreglo parece funcionar.
Tenga en cuenta también que eliminar -XX:+FlightRecorder y defaultrecording=true (como sugirió Kire) todavía funcionó. Dicho esto, no creo que la presencia de defaultrecording=true desencadenara una doble grabación.
Digo esto porque cuando emití el comando jcmd <PID> JFR.check <name> solo obtuve una entrada.