here is part of log. actually record is 419.
ponto:(admin)log/cassandra>grep "to maximum of 64" system.log.1
WARN [MemoryMeter:1] 2012-02-03 00:00:19,444 Memtable.java (line 181)
setting live ratio to maximum of 64 instead of 64.9096047648211
WARN [MemoryMeter:1] 2012-02-08 00:00:17,379 Memtabl
Try reducing memtable_total_space_in_mb config setting. If the problem
is incorrect memory metering that should help.
it does not helps much because difference in correct and cassandra
assumed calculation is way too high. It would require me to shrink
memtables to about 10% of their correct si
>> Are you experiencing memory pressure you think may be attributed to
>> memtables not being flushed frequently enough ?
>
Try reducing memtable_total_space_in_mb config setting. If the problem is
incorrect memory metering that should help.
> i have 3 workload types running in batch. Delete o
Are you experiencing memory pressure you think may be attributed to
memtables not being flushed frequently enough ?
yes
especially delete workload is really good for OOM cassandra for some reason.
liveratio calculation logic also needs to be changed because it is based
on assumption that workloads do not change.
Can you give an example of the sort of workload change you are
thinking of ?
i have 3 workload types running in batch. Delete only workload, insert
only and heavy update (lot of
> liveratio calc should do nothing if memtable has 0 columns.
Sounds reasonable, as counting with zero columns may dramatically change the
live ratio and it may take some time to be counted again.
Please create a ticket on https://issues.apache.org/jira/browse/CASSANDRA
> liveratio calculation l
liveratio calc should do nothing if memtable has 0 columns. I did manual
flush before this.
WARN [MemoryMeter:1] 2012-05-10 13:21:19,430 Memtable.java (line 181)
setting live ratio to maximum of 64 instead of Infinity
INFO [MemoryMeter:1] 2012-05-10 13:21:19,431 Memtable.java (line 186)
CFS(
