Significant memory usage

[RobicToNieMaKomu]

Integration

sentry-spring-boot-starter-jakarta

Java Version

17

Version

7.1.0

Steps to Reproduce

Our service is running on SB 3.1.8 & reactive stack (Webflux).

1. Baseline. Without Sentry, memory consumption oscillates around 700 Mb (committed ~900 Mb, and max is 1.88 Gb).
   
2. After enabling integration on the defaults (with tracing disabled), mem usage went up to the ceiling
   

sentry:
  dsn: ...
  enabled: false
  enableTracing: false
  environment: dev
  serverName: server
  shutdownTimeout: 0

3. After further tuning, I was able to reduce the memory:
   

      SENTRY_MAXBREADCRUMBS: 1
      SENTRY_ENABLEUSERINTERACTIONBREADCRUMBS: false
      SENTRY_DIAGNOSTICLEVEL: fatal
      SENTRY_MAXCACHEITEMS: 0
      SENTRY_ATTACHSTACKTRACE: false

However, the situation is still unacceptable, as integration increased RAM usage by 50% (!).
Can we do something to make it better? Can breadcrumbs be entirely disabled? They are useless in our case as they are not correlated with the request causing an actual error.

Expected Result

Sane memory/CPU footprint.

Actual Result

Gigantic memory consumption.

[adinauer]

@RobicToNieMaKomu thanks for opening this issue. We'll take a look and update here.

[adinauer]

@RobicToNieMaKomu I can confirm, we're using up more memory on startup but after manually triggering GC, it ends up roughly the same.

How I tested

• I fired up our Spring Boot 3 Webflux sample
• let it startup for a bit then manually triggered GC in visualvm a couple times
• sent some requests in using wrk -t2 -c4 -d30s -H "Authorization: Basic dXNlcjpwYXNzd29yZA==" http://127.0.0.1:8080/todo-webclient/1. This sends ~ 4k requests in 30s:

Running 30s test @ http://127.0.0.1:8080/todo-webclient/1
  2 threads and 4 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    28.21ms    9.48ms 174.51ms   93.47%
    Req/Sec    72.24     11.44   101.00     68.91%
  4325 requests in 30.03s, 532.18KB read
Requests/sec:    144.01
Transfer/sec:     17.72KB

• manually triggered GC a couple times again
• reran wrk
• manually triggered GC a couple times again

The endpoint does not record any errors but did create transactions and spans (when Sentry was enabled).

Results

Here's memory with Sentry:

And memory without Sentry:

So with Sentry enabled the server is consuming a lot more memory on startup but it is able to free that back up. Will keep investigating.

Questions

Can you please tell us a bit about your usage of Sentry on the screenshots you provided?

• Do you do any manual capturing of errors, breadcrumbs etc.?
• Other interaction with the Sentry API?
• Are any/many exceptions thrown and recorded by Sentry?
• Roughly how many requests is the server seeing?
• Do you use CRONS? There's another potential memory problem there, see Crons lead to unusual 10% load increase #3165

[adinauer]

@RobicToNieMaKomu if you're not using any of our AOP features (@SentryTransaction, @SentrySpan, @SentryCheckIn annotations) you could try to disable those using sentry.enable-aot-compatibility=true and see if that helps lower the initial memory consumption. From my testing it only used ~ 1/3 of memory on startup this way.

[adinauer]

Here's another screenshot showing memory consumption with above mentioned test procedure and sentry.enable-aot-compatibility=true:

[RobicToNieMaKomu]

Hey @adinauer , thank's for looking into that!

Do you do any manual capturing of errors, breadcrumbs etc.?

We don't create/capture/use breadcrumbs. We catch exceptions above the controller's layer in the @ControllerAdvice class -> @ExceptionHandler methods.

Other interaction with the Sentry API?

Nope.

Are any/many exceptions thrown and recorded by Sentry?

Not many, during a few days, we got <100 occurrences of 3 different Exceptions

Roughly how many requests is the server seeing?

Single pod/instance handles roughly up to 150 RPS

Do you use CRONS?

Nope, at least not directly in our code (not sure if it's used inside Spring itself)

I just set sentry.enable-aot-compatibility=true, will report back tomorrow with the result.