Did you try using zgc or Shenandoah? Either of those would get you max gc pauses ~1ms. For startup time and ram reduction you can also consider graal VM native image, which AOT compiles your code so there is no JIT and no associated warm up and ram usage.
For those that can’t justify a port, there’s also commercial VM’s that are high performance and/or real-time. Old favorite (pdf). Java performance != OpenJDK performance even though that’s the default in many people’s minds. There’s a few implementations with different properties.
It does mention jemalloc, which I believe has been removed as the default allocator in recent Rust versions.
We use Rust for similar things. Mostly small services that need to be performant, resilient (ie. have good understanding of failure scenarios), or both.
It also turns out Jemalloc has a knob for exactly this. It can start its own background threads to do these cleanups without disrupting the application. As can be seen in the image (the vertical dashed lines are deployments), this had the desired effect ‒ one line change in Cargo.toml, but discovering this took a long time and some experimentation.
Which knob is this exactly? This seems like very valuable information!
Did you try using zgc or Shenandoah? Either of those would get you max gc pauses ~1ms. For startup time and ram reduction you can also consider graal VM native image, which AOT compiles your code so there is no JIT and no associated warm up and ram usage.
For those that can’t justify a port, there’s also commercial VM’s that are high performance and/or real-time. Old favorite (pdf). Java performance != OpenJDK performance even though that’s the default in many people’s minds. There’s a few implementations with different properties.
Nice write-up!
It does mention jemalloc, which I believe has been removed as the default allocator in recent Rust versions.
We use Rust for similar things. Mostly small services that need to be performant, resilient (ie. have good understanding of failure scenarios), or both.
Which knob is this exactly? This seems like very valuable information!
Set MALLOC_CONF environment variable to background_thread:true.
don’t feel like it is a good usecase of rust according to the context of the enterprise, scala would be a good choice
How does Scala help with GC pause or RAM usage?
If i understand correctly the post, a new scala application would be able to fit the job.
I don’t think that answered the question
If i understood correctly the post in a new scala application, neither gc or ram usage would be a problem
Did you read the article you just commented on? There’s quite a bit of text with good reasons why Scala was not a good choice for them.
I read the article just once so probably miss what you reference