Caching outfit Terracotta gives away freebie Java doritos
Once you pop, what can't you do again?
Cloud storage: Lower cost and increase uptime
Sometimes you have to give to get. And Terracotta, which specializes in caching programs for Java applications, has decided to give away a freebie version of its BigMemory in-memory caching appliance to try to expand its base of customers who are willing to pay for the full-on and much more scalable version of the product.
Terracotta got its start in 2003 building caching and acceleration programs that scaled across clusters of servers to try to boost the performance of Java applications, getting around some of the garbage collection and heap limits of the Java Virtual Machine. After two years of development, Terracotta launched its first products in 2006, and in the summer of 2009, the firm bought control of the Apache-licensed open source Ehcache alternative to its own programs and slapped the Ehcache APIs in front of its own Java caching wares.
In early 2010, Ehcache was upgraded to provide a second-level cache to Hibernate, and at the end of the year Ehcache was beefed up with an alternate Java heap called BigMemory. More recently, in May 2011, the other Germany software company, Software AG, acquired Terracotta for an undisclosed sum, and at the time there were over 500,000 users worldwide of the Ehcache program.
You would have thought that such a vast installed base would drive plenty of revenues, but apparently Terracotta, which operates as an independent subsidiary of Software AG, wants more - and is willing to split out the BigMemory Java heap as a separate item and give it away to try to get Java shops addicted to it.
With BigMemory Go, according to Mike Allen (head of product management at the Terracotta unit) the company is giving away a single-node implementation of the alternative Java heap that will scale up to 32GB.
A Java heap is a scratch pad for JVMs to store data that is periodically refreshed, leading to performance issues when this garbage collection is done as the size of the heap grows. Of course a larger heap means the JVM doesn't have to go to disk for data, and on a cluster of Java application servers - where data may be spread around many nodes - such a performance hit is a big deal. A typical Java heap size is on the order of 2GB, with sometimes 4GB or 6GB sizes; beyond that and Java's memory management starts to thrash.
The BigMemory Go freebie heap is obviously considerably larger than the kosher JVM heap, and customers can run multiple instances of BigMemory Go on a single server. However - cautions Allen - there will not be an automagic mechanism to move data across those individual heaps as you can do with the full-on BigMemory product, nor across multiple server nodes, which you can do with Ehcache APIs and the Terracotta Java cache clustering software. You can install BigMemory Go on as many servers you want without restriction.
Allen tells El Reg that Terracotta chose the 32GB heap size for the freebie product because it made the company "a little uncomfortable" but that it "really wanted to change behavior" in Java shops. In other words, Terracotta is betting on the Doritos Effect: You can't have just one.
Like BigMemory, BigMemory Go allows for Java heaps to be searched and also has an automatic fast restart feature. Java heaps are backed up to either disk or SSD drives and in the event of a crash, they can be quickly reloaded into the BigMemory heap. The alternative is to extract whatever the data was out of operational systems all over again, and that can take a long time. And if you want to store terabytes of data in memory for quicker operation, you need to back it up to some kind of permanent media and have high availability clustering as well, says Allen.
The BigMemory Java heap has been testing on working systems with up 2TB in size on production systems, and Allen says Terracotta's techies are pushing it to 4TB in the labs right now. The BigMemory heap can be back-ended by a cache cluster that spans "dozens and dozens of nodes."
"A year ago, ten terabytes sounded like a lot of in-memory data," says the Terracotta man. "Now we are doing seals where a hundred terabytes is the starting point."
While BigMemory and BigMemory Go are generally deployed on x86-based servers, the programs are themselves written in Java and can run on any machine that supports a Java stack, according to Allen. And the company has deployed BigMemory on Power, Sparc, and Itanium machinery to date. It is also getting some traction among Hadoop shops, which want to keep subsets of production data in memory on nodes to do very fast data munching on a few terabytes of data rather than the petabytes of data they have in their production clusters.
The full-on BigMemory costs $500 per gigabyte of memory it spans, with volume discounts as server nodes and memory capacity rises. ®
COMMENTS
Bullshit
" A typical Java heap size is on the order of 2GB, with sometimes 4GB or 6GB sizes; beyond that and Java's memory management starts to thrash."
Is this a sponsored story? This is pure weapons grade balonium. First post I could find here, it's old and they happily settled on a 100Gb heap on a large server ->
http://troyjsd.blogspot.co.uk/2009/05/holy-shit-100gb-heap-50-new-gen-less.html
Very old JVMs where heap fragmentation was an issue and this would be true (untuned) - I'd guess pretty much any modern JVM and this is simply untrue.
"Patent pending" though
I am not sure if the community can be won over as easily, especially in the context of http://patents.stackexchange.com/questions/311/to-what-extent-is-a-java-off-heap-management-patent-applicable
Re: Bullshit
Yup.
I wonder if they mean GC pauses. In certain circumstances with a very large heap you can see a GC pause of a minute or two every so often if you have a very large heap (say, the 30gb in the article) and it needs to be GCd. That is in certain circumstances though. At that level, you need to start understanding/ profiling your heap usage and tune the garbage collection.
The big selling point when I used the terracotta product before it was the ability to have memory in use larger than that available on any one server. So you could keep huge object graphs in memory, and they would be split across the cluster, and serialised to disk as a backup. It also propagated thread messaging across the cluster (wait()/ notify()). Very pretty. That was 3/ 4 years ago, no idea what this BigMemory thing is or if its related.
IT infrastructure monitoring strategies
What you need to know about cloud backup
Enabling efficient data center monitoring
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
