3 ms·

What is memory overhead? How much memory Java processes consume comparing to the amount of data a node could handle, assuming there must be no swap (otherwise w

What is memory overhead? How much memory Java processes consume comparing to the amount of data a node could handle, assuming there must be no swap (otherwise we all know what happens to any Java process).

chetanahuja 14y ago
It seems that question has almost completely fallen off the radar today. I've experienced medium sized voldemort clusters eating up huge amounts of extra RAM (of the order of 100% overhead[1]) to avoid falling into pathological GC patterns over long runs. Actually I shouldn't really single out voldemort. The problem is java. Java[2] is a terrible platform to write large in-memory caching servers on. The write and access patterns are a complete mismatch for the assumptions made in the generational GC algorithms that most current JVM's sport. Most caches will evict on an LRU basis, which means that almost all allocations will end up in the old generation heap before finally being evicted. Which is precisely the counter-optimal case for the basic assumptions that the generational GC model relies on (that most objects are short-lived and get swept while still in the "young" heap (which is ultra cheap). Footnotes: [1] "overhead" here means precisely how the parent post defines it. [2] more precisely, the commonly used freely available JVM's that most shops use. There might be better GC implementations (e.g. as claimed by azul) but I don't have any direct experience with them.
- henrikschroder 14y ago
  We got bit by GC issues with our Cassandra cluster, and we had to completely re-design a column family to fix it. It's pretty telling that the development community is moving as many memory structures as possible outside the java heap, each new major release has moved some piece or other. The biggest threat I see to Cassandra is that java in the end won't cut it, that the JVM will limit its performance too much, allowing a competitor to surpass it. Stop-the-world GC pauses are not something you want in a high-performance database solution.
  - chetanahuja 14y ago
    I was in a discussion with a member of the Go development team, bitterly complaining about their decision to go with a GC'd heap as the only way to access memory for something they intended as a "systems programming language". They suggested I link in C data structures for those heap-heavy caching applications :-( As I see it, C and C++ are the only practical options for writing high performance, memory efficient, cache heavy applications for production use in the current tech climate.

chetanahuja 14y ago

It seems that question has almost completely fallen off the radar today. I've experienced medium sized voldemort clusters eating up huge amounts of extra RAM (of the order of 100% overhead[1]) to avoid falling into pathological GC patterns over long runs. Actually I shouldn't really single out voldemort. The problem is java. Java[2] is a terrible platform to write large in-memory caching servers on. The write and access patterns are a complete mismatch for the assumptions made in the generational GC algorithms that most current JVM's sport. Most caches will evict on an LRU basis, which means that almost all allocations will end up in the old generation heap before finally being evicted. Which is precisely the counter-optimal case for the basic assumptions that the generational GC model relies on (that most objects are short-lived and get swept while still in the "young" heap (which is ultra cheap). Footnotes: [1] "overhead" here means precisely how the parent post defines it. [2] more precisely, the commonly used freely available JVM's that most shops use. There might be better GC implementations (e.g. as claimed by azul) but I don't have any direct experience with them.

henrikschroder 14y ago
We got bit by GC issues with our Cassandra cluster, and we had to completely re-design a column family to fix it. It's pretty telling that the development community is moving as many memory structures as possible outside the java heap, each new major release has moved some piece or other. The biggest threat I see to Cassandra is that java in the end won't cut it, that the JVM will limit its performance too much, allowing a competitor to surpass it. Stop-the-world GC pauses are not something you want in a high-performance database solution.
- chetanahuja 14y ago
  I was in a discussion with a member of the Go development team, bitterly complaining about their decision to go with a GC'd heap as the only way to access memory for something they intended as a "systems programming language". They suggested I link in C data structures for those heap-heavy caching applications :-( As I see it, C and C++ are the only practical options for writing high performance, memory efficient, cache heavy applications for production use in the current tech climate.