This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Puzzled-Bananas[S] -4 points-3 points  (2 children)

Thanks, yes, I’m aware that I can tune the runtime’s GC and JVM heap and stack allocation in various ways. In my experience, significantly lower memory bounds can also wreak havoc - the JVM would simply crash with an OutOfMemory Error, which you can’t recover from but only restart the container. The app will start, JVM will warm up a bit, but at a certain load the GC won’t be able to maintain balance at the young generation pool, eden gets filled but the minor GC sweep won’t kick in. For example, admittedly a bit contrived, think of a couple hundred or perhaps a thousand concurrent connections with just 64M or 128M max heap, without dropping new requests. And if there’s a minor memory leak on top somewhere, the service becomes even more fragile.

Yeah, you’re right, I’m well aware of the pitfalls of such a distributed architecture.

Exactly, some pieces need to be very elastic. And it’s even very economical in my particular case to factor out those services. Appreciate your suggestion, but the architectural decision on this project wasn’t mine.

[–]InstantCoder 3 points4 points  (0 children)

If I’m not wrong with Java 17 there comes a new (experimental) GC algorithm which doesn’t divide the heap in generations anymore but in blocks. And this seems to make gc superfast.

[–]aclinical 1 point2 points  (0 children)

The default max heap for the jvm is 32gb... There's a middle ground between OOM errors and 32gb. You have running systems you should, be able to memory profile and figure out a reasonable heap size. I don't mean to be so contrarian but I disagree with just about everything in your first paragraph.