CODEWITHSUNDEEP
javamemorygarbage-collectionjvm
Jsing
Jsing

Reputation: 33

Design issue - Physical memory size and Full Garbage Collection

We are designing new software system architecture. and I am working by project manager.

but there is something on the issue within our team.

Our architect says "System memory should be kept as small as possible because it takes a long time when Full GC occurs. (JVM)

I am not sure of that opinion.

  1. When setting up system memory, what level of Full GC(Garbage Collection) time should be reviewed?

  2. How long will it take if Full GC occurs in a 16GB memory environment?

Upvotes: 1

Views: 192

Answers (2)

tentacle
tentacle

Reputation: 553

How long will it take if Full GC occurs in a 16GB memory environment?

On a small heaps like that the ballpark figure is around 10 sec I guess.

But it's not what you should consider.

When setting up system memory, what level of Full GC(Garbage Collection) time should be reviewed?

All of the times. Whenever full gc occurs it should be reviewed if your application is latency-critical. This is what you should consider.

Full GC is a failure. Failure on a multiple levels.

  • to address memory size available for application
  • to address GC type you use
  • to address the types of workloads
  • to address graceful degradation under the load

and the list goes on

Concurrent GC implicitly relies on a simple fact that it can collect faster then application allocates. When allocation pressure becomes overwhelming GC has two options: slowdown allocations or stop them altogether.

And when it stops, you know, the hell breaks loose, futures time out, clusters brake apart and engineers fear and loathe large heaps for rest of their lives...

It's a common scenario for applications that evolve for years with increasing complexity and loads and lack of overhaul to accommodate to changing world.

It doesn't have to be this way though.

When you build new application from ground up you can design in with performance and latency in mind, with scalability and graceful degradation instead heap size and GC times.

You can split workloads that are not latency-critical but memory-heavy to different VM and run it under good 'ol ParallelGC, and it will outperform any concurrent GC in both throughput and memory overhead. You can run latency-critical tasks under modern state-of-the-art GC like Shenandoah and have sub-second collection pauses on heaps of several TB if you don't mind some-30% memory overhead and considerable amount of CPU overhead.

Let the application and requirements dictate you heap size, not engineers.

Upvotes: 0

Eugene
Eugene

Reputation: 120868

You might be worrying (your "architects") about something that might not be a problem for your throughput to begin with. Until java-9, the default collector is ParallelGC and there are dozens and dozens of applications that have not changed it and are happy with the pause times (and that collector pauses the world every time). So the only real answer is : measure. Enable GC logs and look into it.

On the other hand, if you choose a concurrent collector (you should start with G1), having enough breathing room for it in the heap is crucial. It is a lot more important for Shenandoan and ZGC, since they do everything concurrently. Every time GC initiates a concurrent phase, it works via so-called "barriers", which are basically interceptors for the objects in the heap. These structures used by these barriers require storage. If you will narrow this storage, GC is not going to be happy.

In rather simple words - the more "free" space in the heap, the better your GC will perform.

When setting up system memory, what level of Full GC(Garbage Collection) time should be reviewed?

This is not the correct question. If you are happy with your target response times, this does not matter. If you are not - you start analyzing gc logs and understand what is causing your delays (this is not going to be trivial, though).

How long will it take if Full GC occurs in a 16GB memory environment?

It depends on the collector and on the java version and on the type of Objects to be collected, there is no easy answer. Shenandah and ZGC - this is irrelevant since they do not care on the size of the heap to be scanned. For G1 it is going to be in the range of a "few seconds" most probably. But if you have WeakReferences and finalizers and a java version that is known to handle this not so good, the times to collect is going to be big.

Upvotes: 1

Related Questions