Wow. SO LCS with bloom filter fp chance of 0.1 and an index sampling rate
of 512 on a column family of 1.7billion rows each node yields 100% result
on first sstable reads? That sounds amazing. And I assume this is
cfhistograms output from a node that has been on 512 for a while? ( I
still think
Dean, what is your row size approximately?
We've been using ii = 512 for a long time because of memory issues, but
now - as bloom filter is kept off-heap and memory is not an issue
anymore - I've reverted it to 128 to see if this improves anything. It
seems it doesn't (except that I have less
Argh, now I think that row size has nothing to do with the ii-based
index size/efficiency (I was thinking about the need of reading
index_interval / 2 entries in average from index file before finding the
proper one, but it should not have nothing to do with row size) - forget
the question;
It had only been running for 2 hours back then, but it has been a full 24
hours now and our read ping program is still showing the same read times
pretty consistently.
Dean
On 3/21/13 1:51 AM, Andras Szerdahelyi
andras.szerdahe...@ignitionone.com wrote:
Wow. SO LCS with bloom filter fp chance
Oh, and to give you an idea of memory savings, we had a node at 10G RAM
usage...we had upped a few nodes to 16G from 8G as we don't have our new
nodes ready yet(we know we should be at 8G but we would have a dead
cluster if we did that).
On startup, the initial RAM is around 6-8G. Startup with
I am using LCS so bloom filter fp default for 1.2.2 is 0.1 so my
bloomfilter size is 1.27G RAM(nodetool cfstats)1.7 billion rows each
node.
My cfstats for this CF is attached(Since cut and paste screwed up the
formatting). During testing in QA, we were not sure if index_interval
change was
