Sorry aaron, here are the values you requested
RecentBloomFilterFalsePositives = 5;
BloomFilterFalsePositives = 385260;
uptime of the node is three days and a half, more or less
El mié, 11-05-2011 a las 22:05 +1200, aaron morton escribió:
What are the values for RecentBloomFilterFalsePositives and BloomFilterFalsePositives the non ratio ones ?
Freelance Cassandra Developer
On 11 May 2011, at 19:53, Héctor Izquierdo Seliva wrote:
> El mié, 11-05-2011 a las 14:24 +1200, aaron morton escribió:
>> What version and what were the values for RecentBloomFilterFalsePositives and BloomFilterFalsePositives ?
>> The bloom filter metrics are updated in SSTableReader.getPosition() the only slightly odd thing I can see is that we do not count a key cache hit a a true positive for the bloom filter. If there were a lot of key cache hits and a few false positives the ratio would be wrong. I'll ask around, does not seem to apply to Hectors case though.
> 0.7.5, and I am no longer using key cache. I get the bloom filter stats
> via jmx. BloomFilterFalsePositiveRatio is always stuck at 1.0.
> RecentBloomFilterFalsePositiveRation fluctuates from 0 to 1.0 with no
> intermediate values.
> As for the index interval settings, I changed it from 128 to 256 and
> memory consumption was just a tad lower but read performance was worse
> by a few ms, so not much to gain there.
>> Aaron Morton
>> Freelance Cassandra Developer
>> On 11 May 2011, at 10:38, Chris Burroughs wrote:
>>> On 05/10/2011 02:12 PM, Peter Schuller wrote:
>>>>> That reminds me, my false positive ration is stuck at 1.0, so I guess
>>>>> bloom filters aren't doing a lot for me.
>>>> That sounds unlikely unless you're hitting some edge case like reading
>>>> a particular row that happened to be a collision, and only that row.
>>>> This is from JMX stats on the column family store?
>>> (From jmx) I also see BloomFilterFalseRatio stuck at 1.0 on my
>>> production nodes. The only values that RecentBloomFilterFalseRatio had
>>> over the past several minutes were 0.0 and 1.0. While I can't prove
>>> that isn't accurate, it is very suspicions.
>>> The code looked reasonable until I got to SSTableReader, which was too
>>> complicated to just glance through.