4 ms·
Is there a good decision flowchart on how to chose GC for a particular task/application?
by ordx 4y ago
Is there a good decision flowchart on how to chose GC for a particular task/application?
- deleted 4y ago[deleted]
- brucethemoose2 4y agoI think generational ZGC is going to be the "sane default" soon.
- re-thc 4y agoWould be good to have more benchmarks and articles on G1 vs ZGC once that happens.
- marginalia_nu 4y agoEh, there's probably always going to be a different answer depending on whether you prioritize latency vs throughput.
- popfalushi 4y agoDefault gc depends on how many cpus and ram vm has. With 1 core it is always serialgc, for example. 2 cores and less than 4 gb - concurrent mark and sweep IIRC. G1GC starts a bit later.
- brucethemoose2 4y agoYeah but you dont necessarily want to use those defaults. They strike me as kind of archaic. For low resource use cases, you probably want Graal AOT above all else... which means G1GC or serial, I think.
- agilob 4y agoGraalAOT, do you mean native image or C2 compiler? Neither of these tuning is applicable in a discussion about GCs
- lkorinth 4y agoCMS was removed in 14.
- agilob 4y agoThis is so wrong: >With 1 core it is always serialgc Even with 1 CPU ParallelGC has lower latencies than SerialGC on 1 CPU. SerialGC will be better on environment with limitations on number of threads, not number of CPUs. > 2 cores and less than 4 gb - concurrent mark and sweep IIRC CMS has been deprecated in 11 and removed later in a non-LTS release. JVM ergonomic will automatically turn on >G1GC< when it detects JVM has at least 2 CPUs and 1792Mb of RAM (not heap, memory in total). When either or both numbers are lower then ParallelGC is enabled automatically.
- hashmash 4y agoThe serial and parallel GCs are best used for applications that care more about throughput than latency (pauses). If you only have one CPU core, running multiple threads isn't going to speed up the GC cycle. The parallel collector just adds overhead due to context switching among threads.
- vips7L 4y agoOracle has an overview here [0]. But in general I would say unless you're facing an issue just to let the JVM pick the GC and only really tune -Xmx [0] https://docs.oracle.com/en/java/javase/18/gctuning/introduction-garbage-collection-tuning.html#GUID-326EB4CF-8C8C-4267-8355-21AB04F0D304 https://docs.oracle.com/en/java/javase/18/gctuning/introduct...
- colechristensen 4y agoYup, every once in a while use the various available tools to watch your memory usage patterns and how GC runs. If it looks fine continue to leave it as is.
- exabrial 4y agoAlways start with the question, do you need to optimize? :) Most likely, Probably not! Java is _fast_, and the JVM is pretty good at what it does; 95% of the time merely checking for GC thrashing is all that’s needed. Otherwise, start with G1 and get your Xmx value in the ballpark. VisualVm can help you determine if you're thrashing. Are you GCing like 10+ times per second? Keep an eye on it. If you start hitting giant pause times and 50+ collections a second, you've got problems :) Increase Xmx. (and no, please don't set Xms = Xmx). If you have issues past that, it’s not the garbage collector that needs help; the next step is to audit your code base. Bad code makes any Garage Collector in any language to misbehave. For instance, are you `select *`ing from a table then using the Java streams api to filter rows back from a database? That will cause GC issues :) fix that first. So now if you've got to this point and you still need to optimize, what we've done is just run through the different collectors under load. One of our JVMs is a message broker (ActiveMQ 5.16.x) and we push a couple thousand messages per second through it. We found that Shenandoah actually improved latency for our particular use case, which was more important that throughput and outright performance. Oh, and if your application and usecase is _extremely_ sensitive to latency, forget everything I wrote and contact Azul systems about their Prime collector. They're pretty awesome folks.
- Szpadel 4y agodo you mind explaining to someone that does not do any java dev, but operates some java servers (like elasticsearch, etc) what's wrong with Xms = Xmx? And what is better strategy to set it?
- agilob 4y agoIf you run it in a container the best advice it to leave things with default options. JVM has ergonomic GC options and with adaptive heap sizing. 95% of time you dont need to change anything at all.
- natdempk 4y agoThis Stack Overflow answer is pretty decent: https://stackoverflow.com/a/23284897 https://stackoverflow.com/a/23284897 I think basically the argument is that by setting the min bound lower, you allow the JVM to shrink the heap. This could maybe be beneficial towards reducing pause time because the JVM has less memory to manage overall. That being said, that SO answer also mentions: > Sometimes this behavior doesn't give you the performance benefits you'd expect and in those cases it's best to set mx == ms. I've also seen apps configured this way professionally for similar reasons. You might imagine some app that leads to the JVM pathologically trimming the heap in a way that isn't desirable and thus impacts performance in some subtle way, etc. The answer with a lot of this stuff is usually try both ways, measure, see if you can observe a meaningful difference for your apps/workload for typical/peak traffic. Background: I've worked on Java apps for a few years at reasonable scale and worked on GC pressure issues in that time.
- the8472 4y agosingle-core, latency doesn't matter, low footprint: serial throughput: parallel or G1 balance between latency, footprint and throughput: G1 latency more important than throughput or footprint: ZGC or shenandoah missiles and HFT: Epsilon