>> I don't understand how you reached that conclusion.
>
> On my nodes most memory is consumed by bloom filters. Also 1.0 creates
The point is that just because that's the problem you have, doesn't
mean the default is wrong, since it quite clearly depends on use-case.
If your relative amounts of r
my missunderstanding of FP ratio was based on assumption that ratio is
counted from node start, while it is getRecentBloomFilterFalseRatio()
> I don't understand how you reached that conclusion.
On my nodes most memory is consumed by bloom filters. Also 1.0 creates
larger bloom filters than 0.
> but reported ratio is Bloom Filter False Ratio: 0.00495 which is higher
> than my computed ratio 0.000145. If you were true than reported ratio should
> be lower then mine computed from CF reads because there are more reads to
> sstables then to CF.
The ratio is the ratio of false positives to
Dne 25.12.2011 20:58, Peter Schuller napsal(a):
Read Count: 68844
[snip]
why reported bloom filter FP ratio is not counted like this
10/68844.0
0.00014525594096798558
Because the read count is total amount of reads to the CF, while the
bloom filter is per sstable. The number
> Read Count: 68844
[snip]
> why reported bloom filter FP ratio is not counted like this
>>>> 10/68844.0
> 0.00014525594096798558
Because the read count is total amount of reads to the CF, while the
bloom filter is per sstable. The number of individual read
: 0.00495
Bloom Filter Space Used: 2196632
why reported bloom filter FP ratio is not counted like this
>>> 10/68844.0
0.00014525594096798558
