Terracotta放弃Java垃圾回收机制，使用BigMemory

原文 http://qmkemail.iteye.com/admin/blogs/new

 

Terracotta Says 'Goodbye Java GC, Hello BigMemory

Java的垃圾回收机制一直是性能的瓶颈，而且限制内存的大小，Terracotta使用BigMemory替代JVM的GC，在ENcache中还是比较容易配置的。

Terracotta通过BigMemory分配了200G作为heap内存，没有遇到像Java GC对内存有2G限制的门槛，这是一大突破。

在当今内存越来越便宜情况下，原来超过2G的只能做多个JVM也就是分布式Java，现在不必了。

 

附：

Terracotta Says 'Goodbye Java GC, Hello BigMemory'

Submitted by Mitchell Pronsc... on Tue, 2010/09/14 - 7:18am

• 
• 
• 
• 
• 

Tags:

• Java
• Architecture
• BigMemory
• EHCache
• garbage collection
• hibernate
• Terracotta
• Performance

We Recommend These Resources

How To Protect Your Eclipse RCP Applications

Accelerate SOA Processing with Intel® SSE4.2 Instruction Sets

Java EE & Servlet Containers for ColdFusion Developers

Download Intel Parallel Studio

Build and Release Management: The Real Cost of Do-It-Yourself

Last month, Terracotta told DZone that they were working on a module for Ehcache and Hibernate users that would bypass the Java garbage collection bottleneck.  The severely limited heap size allowed by the Java garbage collector (if you don't want to have significant performance issues) is a problem that has plagued the industry for years.  Terracotta believes that today's memory requirements are finally forcing many to address this issue , and now Terracotta has their own answer - BigMemory.  

DZone interviewed Terracotta CEO Amit Pandey about his company's solution to the GC problem in Java.  BigMemory is a snap-in module that provides off-heap memory storage.  It is a pure Java solution that works with all JVMs and bypasses the Java garbage collector.  You don't even need to be in distributed caching mode to use BigMemory, but it works with both standalone and distributed caches.  Like most Ehcache features, it requires only a few lines of configuration.  BigMemory can also handle hundreds of millions of objects.

Here are the two steps needed to implement BigMemory (when it is released) in Ehcache:

1. Update the Java classpath and startup arguments to include the new
ehcache-2.3 jar and allocate sufficient memory for the BigMemory off-heap
store.
 
2. Update the cache configuration in ehcache.xml to set the size of the
BigMemory off-heap store.

<ehcache>
        <cache name="mycache" maxElementsInMemory="10000"
overflowToOffHeap="true" maxMemoryOffHeap="4G"/>
</ehcache>

"People have been trying to make better garbage collectors for years and years.  Sun/Oracle have been putting a lot of money into solving this problem, but they're only getting incremental improvements."  Terracotta, Pandey says, is able to solve the problem more elegantly because they they "own the cache."  So they decided to write their own memory manager and bypass Java GC completely, freeing developers from difficult and time consuming GC tuning.

Currently in the late beta stages, Pandey told DZone that the responses to BigMemory were very positive from early beta users.  Testing of the memory manager revealed that the responses to increased memory were fast and flat, meaning that it could be counted on to meet performance requirements in a Service Level Agreement.  The greater memory utilization with BigMemory also allows server consolidation.

       App Latency Over Time


Terracotta has tested heap sizes up to 350GB without running into a wall like the 2GB threshold in Java GC.  Pandey says Terracotta is avoiding many of the problems (fragmentation, poor memory management techniques, etc.) that others have encountered when they tried to build their own memory manager.  Pandey says the tagline for BigMemory will be: "Use all the memory you need to get blazingly fast performance."