Looks like someone beat me to it,
https://issues.apache.org/jira/browse/CASSANDRA-4321
On Fri, Jun 8, 2012 at 9:06 AM, Javier Sotelo wrote:
> Different node same hardware now gets the stack overflow error but I found
> the part of the stack trace that is more interesting:
>
>
> at
> com.g
Different node same hardware now gets the stack overflow error but I found
the part of the stack trace that is more interesting:
at com.google.common.collect.Iterators$5.hasNext(Iterators.java:517)
at com.google.common.collect.Iterators$3.hasNext(Iterators.java:114)
at com
nodetool ring showed 34.89GB load. Upgrading from 1.1.0. One small keyspace
with no compression, about 250MB. The rest taken by the second keyspace
with leveled compaction and snappy compressed.
The blade is an Intel(R) Xeon(R) CPU E5620 @ 2.40GHz with 6GB of RAM.
On Thu, Jun 7, 2012 at 2:52 AM,
How much data do you have on the node ?
Was this a previously running system that was upgraded ?
> with disk_access_mode mmap_index_only and mmap I see OOM map failed error on
> SSTableBatchOpen thread
Do you have the stack trace from the log ?
> ERROR [CompactionExecutor:6] 2012-06-06 20:24:1
Hi All,
On SuSe Linux blade with 6GB of RAM.
with disk_access_mode mmap_index_only and mmap I see OOM map failed error
on SSTableBatchOpen thread. cat /proc//maps shows a peak of 53521
right before it dies. vm.max_map_count = 1966080 and /proc//limits
shows unlimited locked memory.
with disk_acc
