#Spring Boot + Virtual Threads heap size problem

1 messages · Page 1 of 1 (latest)

severe cloak
#

I am wondering why nobody talks about unbound virtual threads creation. I have some load tests for testing platform threads vs virtual threads for my app in kubernetes cluster. With virtual threads enabled 3 instances keep restarting due to enormous RAM consumption.
Is there any workaround or back-pressure mechanism to prevent unbound virtual threads creation?

azure atlasBOT
#

<@&987246841693360200> please have a look, thanks.

#

Here is an AI assisted attempt to answer your question 🤖. Maybe it helps! In any case, a human is on the way 👍. To continue talking to the AI, you can use </chatgpt:1108714622413963314>.

#
TJ-Bot
I am wondering why nobody talks about unbound virtual threads creation. I have some load tests for testing platform threads vs virtual threads for my app in kubernetes cluster. With virtual threads enabled 3 instances keep restarting due to enormous RAM co

plication built on Spring Boot. I noticed that when using virtual threads, the application consumes a lot more memory compared to platform threads. After some investigation, I found out that virtual threads are not bound by default, which means they do not have a maximum stack size like platform threads. This can lead to excessive memory consumption, especially in scenarios where a large number of virtual threads are created.

To address this issue, you can specify a maximum stack size for virtual threads by setting the LoomStackSizeMax flag in your JVM options. This will limit the amount of memory each virtual thread can consume and prevent excessive heap usage.

Additionally, you can also control the number of virtual threads created by managing the thread pool size in your application. By limiting the number of concurrent virtual threads, you can prevent excessive memory usage and ensure optimal performance.

In conclusion, if you are experiencing heap size problems with Spring Boot and virtual threads, consider setting a maximum stack size for virtual threads and managing the thread pool size to control memory consumption. This will help optimize memory usage and improve the overall performance of your application.

- AI generated response
opaque eagle
#

but how can you even end up with enormous ram consumption?

#

you would have to send million of requests in a short time

full cloak
#

or have each do a lot of allocation...

severe cloak
#

I've tested the app with 500rps. With platform threads each pod consumed 1gb (1.5gb limit) of ram but with virtual threads kuber shut them down with OOMKill

#

The difference is huge. I assume it happens because virtual threads provide better throughput which results in more RAM consumption

frozen olive
oblique crane
#

it depends on how exactly are you creating threads

severe cloak
oblique crane
#

The point of virtual threads is to not bound them

#

They are more like tasks

#

I'd inspect the heap and maybe do some jfr monitoring for events

#

To see what exactly is happening

blazing oxide
#

@severe cloak yeah so the "problem" is that virtual threads aren't pooled

#

before when you had a 500 thread pool or whatever, you had a hard limit on concurrency for everything else in the system

#

what simon said is one way - basically just make sure you only have 500 virtual threads

#

but a better way is to figure out what the concurrency limits should be for your downstream services

severe cloak
#

ok, thank you all for help