Java实时应用程序的垂直扩展

Question

With GC tuning I am successfully able to get performance for real-time java applications and avoiding recognizable GC pauses. But, this holds good up to ~20 GB of heap space.

Decrease in the hardware cost has made even 100GB of RAM machines affordable. But, still with Java due to GC pauses, higher heap sizes like 50 GB can send you into nightmare at regular times.

I understand that there are options like off-heap and distributed-heap. But, off-heap has a disadvantage of se/derialization and distributed-heap on the hand increases maintenance cost. Further, in distributed-heap you are actually not fully utilizing RAM (say 64 GB) which these days are becoming common as commodity.

Therefore, to fully utilize the potential of RAM, what are the good solutions for vertical scaling of Java applications?

Answer 1

I am working on a primitive collections library called Banana . Banana addresses those exact issues. It supports LinkedLists, HashMaps and possibly other data structures soon without the overhead of keeping N objects. basically - the entire storage can be inside an int[] array (or many).

While I did not yet officially released it, most of it is well tested and I have already ran it successfully on servers with 144GB of RAM, maintaining fast and consistent performance without any GC pauses.

Check out this hash-map benchmark to get an idea on how to use Banana to store data and how well it scales vertically.

https://github.com/omry/banana/wiki/Long-to-fixed-size-object-benchmark

See the wiki for more info.

Answer 2

Garbage Collection time is a function of the number of live objects in your heap. This means that if your allocation rate is very high but the number of live objects is always low, you can use as much RAM as you want without having significant pauses.

This statement is particularly true with the Troughput Collector ( -XX:+UseParallelOldGC ).

If you use CMS, then you probably want to check its incremental mode ( -XX:+CMSIncrementalMode ). It will trigger smaller CMS cycles to clean a smaller fraction of your heap, while leveraging your hardware and without STW pauses.

If CMS is not an option, then you should have a look at G1 ( -XX:+UseG1GC ), which is a new Garbage Collector designed for large heaps. The principle is : clean only several regions of the heap at each cycle but make sure these regions contains a lot of dead objects (quick gains).

Hope that helps !

Sources :

• http://www.infoq.com/articles/G1-One-Garbage-Collector-To-Rule-Them-All
• http://jvm-options.tech.xebia.fr/

Answer 3

I did some research on scaling heap size of JVM. You can read more details here and here .

Main conclusion: young GC pause have two components constant and variable.

Constant component depends on old space size and for 64GiB, I expect it to be 80ms-120ms (dependent on hardware).

Variable component depends on surviving of objects in young space (thus it changes from collection to collection). It is really application specific, but you usually can reduce it by reducing young space (at cost of more frequent pauses).

In your case for 4 GiB of young space you have 500ms. Assuming variable component is 400ms,if you reduce young space to 1 GiB you should have ~200ms pauses (but 2 times per second).

Another approach is to use more CPU cores, young GC paralleling extremely well .

Answer 4

G1 and Shenandoah (experimental) garbage collectors provide great elasticity and unlock vertical scaling for Java applications optimizing memory usage according to the current load. More specifics how it works are at the article Minimize Java Memory Usage with the Right Garbage Collector