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
With Spring Boot 2.x, actuator metric collection around web-request timing is enabled by default. Using Jersey as the ReST provider, results in JavaHeapErrors and OOM under moderate load when target GET requests to an endpoint with variable path elements.
I've published a repo here containing the test project to help reproduce the issue. The service is configured in the build to expose the java management port at 9010 so that something like visualvm can address it.
Notes:
setting management.metrics.web.server.auto-time-requests=false prevents the OOM from occurring (GC can catch up)
excluding actuator as a dependency also fixes the issue
adding a metric filter to exclude http.server.requests also fixes the issue.
NOT using Jersey avoids the issue
NOT using variable element URLs avoids the issue.
Project contains a branch for the performance baseline without auto-timing enabled. The project is docker based with some basic instructions included.
The text was updated successfully, but these errors were encountered:
Same issue here after upgrading to spring boot 2. Having variable path elements is practically always the case so this is quite annoying.
Apparently micrometer timers have a large memory footprint.
With Spring Boot 2.x, actuator metric collection around web-request timing is enabled by default. Using Jersey as the ReST provider, results in JavaHeapErrors and OOM under moderate load when target GET requests to an endpoint with variable path elements.
I've published a repo here containing the test project to help reproduce the issue. The service is configured in the build to expose the java management port at 9010 so that something like visualvm can address it.
Notes:
management.metrics.web.server.auto-time-requests=false
prevents the OOM from occurring (GC can catch up)http.server.requests
also fixes the issue.Project contains a branch for the performance baseline without auto-timing enabled. The project is docker based with some basic instructions included.
The text was updated successfully, but these errors were encountered: