Is Terracotta’s BigMemory a big thing?

阅读更多

转至http://www.kafka0102.com/2010/09/343.html

Terracotta最近推出了个新东西–BigMemory，使得Infoq上的这篇Terracotta’s BigMemory Aiming to Eliminate Garbage Collection for Java Caches文章引来长长的争论。像GigaSpaces、Infinispan等和Terracotta有竞争关系的商业或开源的对手，对BigMemory的诸多方面提出了疑问和质疑。如果BigMemory真的如Terracotta吹的那般好，那些竞争对手该情何以堪？就算它真的好，也要挑出它的不是，比如就有评论说现在都分布式年代了，还搞什么单JVM实例优化？暂且放下这些争论，看看BigMemory是个怎样的东西，值得大家如此大动神经。

JVM GC的问题可以说是“臭名昭著”，尽管现在一台服务器的内存可以动辄几十G到上百G，但单个JVM实例并不能充分利用硬件提供的内存资源，因为JVM内存容量越大，由GC带来的应用“暂停”现象就越明显。所以，通常单个JVM实例的内存容量要控制在一定范围内。这也使得，为了能有效利用机器的内存，一台机器会部署多个JVM实例。而对于需要大规模内存的Java应用，比如Cache系统，想不分布式都不行。

但Terracotta说了，他们的大多数客户并不需要分布式的Cache系统，单个Ehcache实例就够用了，只是客户们希望单个Ehcache实例能支持更大的内存容量，并且不要有性能问题。所以，BigMemory被创造出来了。BigMemory不是在JVM堆上分配内存的（off heap），内存的分配与回收不受GC控制，容量方面可以达到物理内存规模。因为BigMemory不是开源的，Terracotta没有透露出BigMemory的实现原理，但其使用文档指出，使用BigMemory需要配置MaxDirectMemorySize选项，并且其是100%Java开发的，所以BigMemory应该是基于DirectBuffer的。至于BigMemory的技术难度和复杂性，我还不好揣测，是不是通过DirectBuffer分配了一块大的ByteArray，然后有一套有效的堆外内存管理机制呢？

说说BigMemory的效果吧。以Ehcache为例，它原来支持两层store，即MemStore和DiskStore，MemStore的大小受限于GC影响，一般控制在（4G？,我有些记不清了，它的文档应该有说明的）以下为好；而DiskStore相比于MemStore，性能方面有百倍的差距，更适合做个备份。现在引入BigMemory后，Ehcache的Stroe就有三层：MemStore可以控制在较好的规模（比如2G），使得GC不会对应用服务产生严重的影响，并且能cache住大多数热的内容；BigMemory可以给出更大的容量，cache那些不是很热的内容，因为BigMemory保存的是对象序列化后的内容，所以对BigMemory管理的对象操作有个序列化和反序列化过程，使得BigMemory相比MemStore会有10倍左右的性能损失，但相比于分布式的cache读取，这些性能损失是已经很小了；而DiskStore，它就真的适合做个备份，以提升应用重启动时间。

如果Terracotta给出的数据和评测准确，我觉得BigMemory是个很不错的东西。即便是应用的分布式化盛行，但提升单个JVM的内存使用效果对很多场景还是很有价值的，君不见还有大公司热衷于mysql的单机优化吗？不知道是否会有有心人做出个通用的开源的BigMemory出来，甚至集成到JDK中，以造福Javaer们呢？