Re: [SOLVED] Very high memory utilization (not caused by mmap on sstables)

Sorry for spam again. :-) I think I find the root cause. Here is a bug report[1] on memory leak of ParNewGC. It is solved by OpenJDK 1.6.0_20(IcedTea6 1.9.2)[2]. So the suggestion is: for who runs cassandra of Ubuntu 10.04, please upgrade OpenJDK to the latest version. [1] http://bugs.sun.com/

Re: Very high memory utilization (not caused by mmap on sstables)

The test node is behind a firewall. So I took some time to find a way to get JMX diagnostic information from it. What's interesting is, both the HeapMemoryUsage and NonHeapMemoryUsage reported by JVM is quite reasonable. So, it's a myth why the JVM process maps such a big anonymous memory region.

Re: Very high memory utilization (not caused by mmap on sstables)

After investigating it deeper, I suspect it's native memory leak of JVM. The large anonymous map on lower address space should be the native heap of JVM, but not java object heap. Has anybody met it before? I'll try to upgrade the JVM tonight. best regards, hanzhu On Thu, Dec 16, 2010 at 10:

Re: mmap:ed i/o and buffer sizes

On Fri, Dec 10, 2010 at 2:45 PM, Peter Schuller wrote: > I was looking closer at sliced_buffer_size_in_kb and > column_index_size_in_kb and reached the conclusion that for the > purpose of I/O, these are irrelevant when using mmap:ed I/O mode > (which makes sense, since there is no way to use a "

Build failed in Hudson: Cassandra-0.7 #86

See Changes: [jbellis] merge from 0.6 -- [...truncated 1394 lines...] [junit] Testsuite: org.apache.cassandra.db.MultitableTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elaps

Build failed in Hudson: Cassandra-0.7 #85

See Changes: [jbellis] merge from 0.6 [jbellis] merge from 0.6 -- [...truncated 1119 lines...] [javadoc] Loading source file

Hudson build is back to normal : Cassandra #631

See

Re: Internal error processing batch_mutate

On Dec 14, 2010, at 23:39, Jonathan Ellis wrote: > Looks like https://issues.apache.org/jira/browse/CASSANDRA-1860, which we > think is fixed in latest 0.7 branch (as of yesterday). Yes, as posted on the user list, seems to run stable now. Thanks! > On Sat, Dec 11, 2010 at 6:40 AM, Timo Nentwig

A new project, finding a Champion

Hello everyone: we have a new project which is a key-value database named TreapDB. It is based onTreap data structure a randomized balanced binary search tree. TreapDB is compatible with memcached command, so you can set and get data by using normal memcached client. TreapDB also support other op