True, the high hit rate has translated to low read latency. But the
question is how can I debug the reason for low hit rate now assuming read
patterns haven't changed.
Thanks,
Eran Chinthaka Withana
On Fri, Feb 17, 2012 at 3:07 PM, Jonathan Ellis wrote:
> I suspect the main difference is that
I suspect the main difference is that 2-3 weeks ago almost none of
your reads had to hit disk.
On Fri, Feb 17, 2012 at 1:53 PM, Eran Chinthaka Withana
wrote:
> I never used JMX for any changes and use JMX only for monitoring. All my
> updates goes through schema updates.
>
> To give you little bi
I never used JMX for any changes and use JMX only for monitoring. All my
updates goes through schema updates.
To give you little bit more context (not sure whether this will help but
anyway), about 2-3 weeks back the read latency was 4-8ms with about 90-95%
key cache hit rate. But after that point
Only thing I can think of is that if you've set the cache size
manually over JMX it will preserve that size if you change it via a
schema update.
On Fri, Feb 17, 2012 at 12:10 AM, Eran Chinthaka Withana
wrote:
> Hi Jonathan,
>>
>>
>> > For some reason 16637958 (the keys cached) has become a golde
ah, I missed the part about "key" cache .. I read "row" cache. thx
On 2/16/12 6:14 PM, "Jonathan Ellis" wrote:
>Look for this code in SSTableReader.getPosition:
>
>Pair unifiedKey = new
>Pair(descriptor, decoratedKey);
>Long cachedPosition = getCachedPosition(unifiedKey,
Hi Jonathan,
>
> > For some reason 16637958 (the keys cached) has become a golden number
> and I
> > don't see key cache increasing beyond that.
>
> 16637958 is your configured cache capacity according to the cfstats you
> pasted.
this is another weird part. If you look at the schema[1] (pasted
all in the most recent sstable, by this, I
think the read performace will be better.
2012-02-17
zhangcheng
发件人： Jonathan Ellis
发送时间： 2012-02-17 10:13:20
收件人： user
抄送：
主题： Re: Key cache hit rate issue
On Thu, Feb 16, 2012 at 3:52 PM, Eran Chinthaka Withana
wrote:
> Thanks
Thanks, Jonathan. I got it.
2012-02-17
zhangcheng
发件人： Jonathan Ellis
发送时间： 2012-02-17 10:15:05
收件人： user
抄送：
主题： Re: Key cache hit rate issue
Look for this code in SSTableReader.getPosition:
Pair unifiedKey = new
Pair(descriptor, decoratedKey);
Long
according to the read process, the key of the keycache should be the row key.
2012-02-17
zhangcheng
发件人： Todd Burruss
发送时间： 2012-02-17 06:23:47
收件人： user@cassandra.apache.org
抄送：
主题： Re: Key cache hit rate issue
jonathan, you said the key to the cache is key + sstable? looking
Look for this code in SSTableReader.getPosition:
Pair unifiedKey = new
Pair(descriptor, decoratedKey);
Long cachedPosition = getCachedPosition(unifiedKey, true);
On Thu, Feb 16, 2012 at 4:23 PM, Todd Burruss wrote:
> jonathan, you said the key to the cache is key + sstabl
On Thu, Feb 16, 2012 at 3:52 PM, Eran Chinthaka Withana
wrote:
> Thanks for the reply. Yes there is a possibility that the keys can be
> distributed in multiple SSTables, but my data access patterns are such that
> I always read/write the whole row. So I expect all the data to be in the
> same SST
> To: "user@cassandra.apache.org"
> Subject: Re: Key cache hit rate issue
>
> Hi Jonathan,
>
> Thanks for the reply. Yes there is a possibility that the keys can be
> distributed in multiple SSTables, but my data access patterns are such that
> I always read/write t
jonathan, you said the key to the cache is key + sstable? looking at the
code it looks like a DecoratedKey is the "row key". how does sstable come
into play?
On 2/16/12 1:20 PM, "Jonathan Ellis" wrote:
>So, you have roughly 1/6 of your (physical) row keys cached and about
>1/4 cache hit rate,
: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>"
mailto:user@cassandra.apache.org>>
Subject: Re: Key cache hit rate issue
Hi Jonathan,
Thanks for the reply. Yes there is a possibility that the keys can be
distributed in multiple SSTables, but my data access pat
On 17/02/2012 8:53 AM, "Eran Chinthaka Withana"
wrote:
>
> Hi Jonathan,
>
> Thanks for the reply. Yes there is a possibility that the keys can be
distributed in multiple SSTables, but my data access patterns are such that
I always read/write the whole row. So I expect all the data to be in the
sam
Hi Jonathan,
Thanks for the reply. Yes there is a possibility that the keys can be
distributed in multiple SSTables, but my data access patterns are such that
I always read/write the whole row. So I expect all the data to be in the
same SSTable (please correct me if I'm wrong).
For some reason 16
So, you have roughly 1/6 of your (physical) row keys cached and about
1/4 cache hit rate, which doesn't sound unreasonable to me. Remember,
each logical key may be spread across multiple physical sstables --
each (key, sstable) pair is one entry in the key cache.
On Thu, Feb 16, 2012 at 1:48 PM,
Hi Aaron,
Here it is.
Keyspace:
Read Count: 1123637972
Read Latency: 5.757938114343114 ms.
Write Count: 128201833
Write Latency: 0.0682576607387509 ms.
Pending Tasks: 0
Column Family: YY
SSTable count: 18
Space used (live): 103318720685
Space used (total): 103318720685
Number of Keys (est
> Its in the order of 261 to 8000 and the ratio is 0.00. But i guess 8000 is
> bit high. Is there a way to fix/improve it?
Sorry I don't understand what you mean. But if the ratio is 0.0 all is good.
Could you include the full output from cfstats for the CF you are looking at ?
Cheers
Its in the order of 261 to 8000 and the ratio is 0.00. But i guess 8000 is
bit high. Is there a way to fix/improve it?
Thanks,
Eran Chinthaka Withana
On Tue, Feb 14, 2012 at 3:42 PM, aaron morton wrote:
> Out of interest what does cfstats say about the bloom filter stats ? A
> high false positi
Out of interest what does cfstats say about the bloom filter stats ? A high
false positive could lead to a low key cache hit rate.
> Also, is there a way to warm start the key cache, meaning pre-load the amount
> of keys I set as keys_cached?
See key_cache_save_period when creating the CF.
Che
Hi,
I'm using Cassandra 1.0.7 and I've set the keys_cached to about 80% (using
the numerical values). This is visible in cfstats too. But I'm getting less
than 20% (or sometimes even 0%) key cache hit rate. Well, the data access
pattern is not the issue here as I know they are retrieving the same
22 matches
Mail list logo
