You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by preetika tyagi <pr...@gmail.com> on 2017/03/11 20:15:42 UTC
Row cache tuning
Hi,
I'm new to Cassandra and trying to get a better understanding on how the
row cache can be tuned to optimize the performance.
I came across think this article:
https://docs.datastax.com/en/cassandra/3.0/cassandra/operations/opsConfiguringCaches.html
And it suggests not to even touch row cache unless read workload is > 95%
and mostly rely on machine's default cache mechanism which comes with OS.
The default row cache size is 0 in cassandra.yaml file so the row cache
won't be utilized at all.
Therefore, I'm wondering how exactly I can decide to chose to tweak row
cache if needed. Are there any good pointers one can provide on this?
Thanks,
Preetika
Re: Row cache tuning
Posted by Thomas Julian <th...@zoho.com>.
Hi Matija,
Leveraging page cache yields good results and if accounted for can provide you with performance increase on read side
I would like to leverage the page cache to improve read performance. How this can be done?
Best Regards,
Julian.
---- On Mon, 13 Mar 2017 03:42:32 +0530 preetika tyagi <preetikatyagi@gmail.com> wrote ----
I see. Thanks, Arvydas!
In terms of eviction policy in the row cache, does a write operation invalidates only the row(s) which are going be modified or the whole partition? In older version of Cassandra, I believe the whole partition gets invalidated even if only one row is modified. Is that still true for the latest release (3.10). I browsed through many online articles and tutorials but cannot find information on this.
On Sun, Mar 12, 2017 at 2:25 PM, Arvydas Jonusonis <arvydas.jonusonis@gmail.com> wrote:
You can experiment quite easily without even needing to restart the Cassandra service.
The caches (row and key) can be enabled on a table-by-table basis via a schema directive. But the cache capacity (which is the one that you referred to in your original post, set to 0 in cassandra.yaml) is a global setting and can be manipulated via JMX or nodetool (nodetool setcachecapacity).
Arvydas
On Sun, Mar 12, 2017 at 9:46 AM, preetika tyagi <preetikatyagi@gmail.com> wrote:
Thanks, Matija! That was insightful.
I don't really have a use case in particular, however, what I'm trying to do is to figure out how the Cassandra performance can be leveraged by using different caching mechanisms, such as row cache, key cache, partition summary etc. Of course, it will also heavily depend on the type of workload but I'm trying to gain more understanding of what's available in the Cassandra framework.
Also, I read somewhere that either row cache or key cache can be turned on for a specific table, not both. Based on your comment, I guess the combination of page cache and key cache is used widely for tuning the performance.
Thanks,
Preetika
On Sat, Mar 11, 2017 at 2:01 PM, Matija Gobec <matija0204@gmail.com> wrote:
Hi,
In 99% of use cases Cassandra's row cache is not something you should look into. Leveraging page cache yields good results and if accounted for can provide you with performance increase on read side.
I'm not a fan of a default row cache implementation and its invalidation mechanism on updates so you really need to be careful when and how you use it. There isn't much to configuration as there is to your use case. Maybe explain what are you trying to solve with row cache and people can get into discussion with more context.
Regards,
Matija
On Sat, Mar 11, 2017 at 9:15 PM, preetika tyagi <preetikatyagi@gmail.com> wrote:
Hi,
I'm new to Cassandra and trying to get a better understanding on how the row cache can be tuned to optimize the performance.
I came across think this article: https://docs.datastax.com/en/cassandra/3.0/cassandra/operations/opsConfiguringCaches.html
And it suggests not to even touch row cache unless read workload is > 95% and mostly rely on machine's default cache mechanism which comes with OS.
The default row cache size is 0 in cassandra.yaml file so the row cache won't be utilized at all.
Therefore, I'm wondering how exactly I can decide to chose to tweak row cache if needed. Are there any good pointers one can provide on this?
Thanks,
Preetika
Re: Row cache tuning
Posted by preetika tyagi <pr...@gmail.com>.
I see. Thanks, Arvydas!
In terms of eviction policy in the row cache, does a write operation
invalidates only the row(s) which are going be modified or the whole
partition? In older version of Cassandra, I believe the whole partition
gets invalidated even if only one row is modified. Is that still true for
the latest release (3.10). I browsed through many online articles and
tutorials but cannot find information on this.
On Sun, Mar 12, 2017 at 2:25 PM, Arvydas Jonusonis <
arvydas.jonusonis@gmail.com> wrote:
> You can experiment quite easily without even needing to restart the
> Cassandra service.
>
> The caches (row and key) can be enabled on a table-by-table basis via a
> schema directive. But the cache capacity (which is the one that you
> referred to in your original post, set to 0 in cassandra.yaml) is a global
> setting and can be manipulated via JMX or nodetool (nodetool
> setcachecapacity
> <https://docs.datastax.com/en/cassandra/2.1/cassandra/tools/toolsSetCacheCapacity.html>
> ).
>
> Arvydas
>
> On Sun, Mar 12, 2017 at 9:46 AM, preetika tyagi <pr...@gmail.com>
> wrote:
>
>> Thanks, Matija! That was insightful.
>>
>> I don't really have a use case in particular, however, what I'm trying to
>> do is to figure out how the Cassandra performance can be leveraged by using
>> different caching mechanisms, such as row cache, key cache, partition
>> summary etc. Of course, it will also heavily depend on the type of workload
>> but I'm trying to gain more understanding of what's available in the
>> Cassandra framework.
>>
>> Also, I read somewhere that either row cache or key cache can be turned
>> on for a specific table, not both. Based on your comment, I guess the
>> combination of page cache and key cache is used widely for tuning the
>> performance.
>>
>> Thanks,
>> Preetika
>>
>> On Sat, Mar 11, 2017 at 2:01 PM, Matija Gobec <ma...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> In 99% of use cases Cassandra's row cache is not something you should
>>> look into. Leveraging page cache yields good results and if accounted for
>>> can provide you with performance increase on read side.
>>> I'm not a fan of a default row cache implementation and its invalidation
>>> mechanism on updates so you really need to be careful when and how you use
>>> it. There isn't much to configuration as there is to your use case. Maybe
>>> explain what are you trying to solve with row cache and people can get into
>>> discussion with more context.
>>>
>>> Regards,
>>> Matija
>>>
>>> On Sat, Mar 11, 2017 at 9:15 PM, preetika tyagi <preetikatyagi@gmail.com
>>> > wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm new to Cassandra and trying to get a better understanding on how
>>>> the row cache can be tuned to optimize the performance.
>>>>
>>>> I came across think this article: https://docs.datastax
>>>> .com/en/cassandra/3.0/cassandra/operations/opsConfiguringCaches.html
>>>>
>>>> And it suggests not to even touch row cache unless read workload is >
>>>> 95% and mostly rely on machine's default cache mechanism which comes with
>>>> OS.
>>>>
>>>> The default row cache size is 0 in cassandra.yaml file so the row cache
>>>> won't be utilized at all.
>>>>
>>>> Therefore, I'm wondering how exactly I can decide to chose to tweak row
>>>> cache if needed. Are there any good pointers one can provide on this?
>>>>
>>>> Thanks,
>>>> Preetika
>>>>
>>>
>>>
>>
>
Re: Row cache tuning
Posted by Arvydas Jonusonis <ar...@gmail.com>.
You can experiment quite easily without even needing to restart the
Cassandra service.
The caches (row and key) can be enabled on a table-by-table basis via a
schema directive. But the cache capacity (which is the one that you
referred to in your original post, set to 0 in cassandra.yaml) is a global
setting and can be manipulated via JMX or nodetool (nodetool
setcachecapacity
<https://docs.datastax.com/en/cassandra/2.1/cassandra/tools/toolsSetCacheCapacity.html>
).
Arvydas
On Sun, Mar 12, 2017 at 9:46 AM, preetika tyagi <pr...@gmail.com>
wrote:
> Thanks, Matija! That was insightful.
>
> I don't really have a use case in particular, however, what I'm trying to
> do is to figure out how the Cassandra performance can be leveraged by using
> different caching mechanisms, such as row cache, key cache, partition
> summary etc. Of course, it will also heavily depend on the type of workload
> but I'm trying to gain more understanding of what's available in the
> Cassandra framework.
>
> Also, I read somewhere that either row cache or key cache can be turned on
> for a specific table, not both. Based on your comment, I guess the
> combination of page cache and key cache is used widely for tuning the
> performance.
>
> Thanks,
> Preetika
>
> On Sat, Mar 11, 2017 at 2:01 PM, Matija Gobec <ma...@gmail.com>
> wrote:
>
>> Hi,
>>
>> In 99% of use cases Cassandra's row cache is not something you should
>> look into. Leveraging page cache yields good results and if accounted for
>> can provide you with performance increase on read side.
>> I'm not a fan of a default row cache implementation and its invalidation
>> mechanism on updates so you really need to be careful when and how you use
>> it. There isn't much to configuration as there is to your use case. Maybe
>> explain what are you trying to solve with row cache and people can get into
>> discussion with more context.
>>
>> Regards,
>> Matija
>>
>> On Sat, Mar 11, 2017 at 9:15 PM, preetika tyagi <pr...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I'm new to Cassandra and trying to get a better understanding on how the
>>> row cache can be tuned to optimize the performance.
>>>
>>> I came across think this article: https://docs.datastax
>>> .com/en/cassandra/3.0/cassandra/operations/opsConfiguringCaches.html
>>>
>>> And it suggests not to even touch row cache unless read workload is >
>>> 95% and mostly rely on machine's default cache mechanism which comes with
>>> OS.
>>>
>>> The default row cache size is 0 in cassandra.yaml file so the row cache
>>> won't be utilized at all.
>>>
>>> Therefore, I'm wondering how exactly I can decide to chose to tweak row
>>> cache if needed. Are there any good pointers one can provide on this?
>>>
>>> Thanks,
>>> Preetika
>>>
>>
>>
>
Re: Row cache tuning
Posted by preetika tyagi <pr...@gmail.com>.
Thanks, Matija! That was insightful.
I don't really have a use case in particular, however, what I'm trying to
do is to figure out how the Cassandra performance can be leveraged by using
different caching mechanisms, such as row cache, key cache, partition
summary etc. Of course, it will also heavily depend on the type of workload
but I'm trying to gain more understanding of what's available in the
Cassandra framework.
Also, I read somewhere that either row cache or key cache can be turned on
for a specific table, not both. Based on your comment, I guess the
combination of page cache and key cache is used widely for tuning the
performance.
Thanks,
Preetika
On Sat, Mar 11, 2017 at 2:01 PM, Matija Gobec <ma...@gmail.com> wrote:
> Hi,
>
> In 99% of use cases Cassandra's row cache is not something you should look
> into. Leveraging page cache yields good results and if accounted for can
> provide you with performance increase on read side.
> I'm not a fan of a default row cache implementation and its invalidation
> mechanism on updates so you really need to be careful when and how you use
> it. There isn't much to configuration as there is to your use case. Maybe
> explain what are you trying to solve with row cache and people can get into
> discussion with more context.
>
> Regards,
> Matija
>
> On Sat, Mar 11, 2017 at 9:15 PM, preetika tyagi <pr...@gmail.com>
> wrote:
>
>> Hi,
>>
>> I'm new to Cassandra and trying to get a better understanding on how the
>> row cache can be tuned to optimize the performance.
>>
>> I came across think this article: https://docs.datastax
>> .com/en/cassandra/3.0/cassandra/operations/opsConfiguringCaches.html
>>
>> And it suggests not to even touch row cache unless read workload is > 95%
>> and mostly rely on machine's default cache mechanism which comes with OS.
>>
>> The default row cache size is 0 in cassandra.yaml file so the row cache
>> won't be utilized at all.
>>
>> Therefore, I'm wondering how exactly I can decide to chose to tweak row
>> cache if needed. Are there any good pointers one can provide on this?
>>
>> Thanks,
>> Preetika
>>
>
>
Re: Row cache tuning
Posted by Matija Gobec <ma...@gmail.com>.
Hi,
In 99% of use cases Cassandra's row cache is not something you should look
into. Leveraging page cache yields good results and if accounted for can
provide you with performance increase on read side.
I'm not a fan of a default row cache implementation and its invalidation
mechanism on updates so you really need to be careful when and how you use
it. There isn't much to configuration as there is to your use case. Maybe
explain what are you trying to solve with row cache and people can get into
discussion with more context.
Regards,
Matija
On Sat, Mar 11, 2017 at 9:15 PM, preetika tyagi <pr...@gmail.com>
wrote:
> Hi,
>
> I'm new to Cassandra and trying to get a better understanding on how the
> row cache can be tuned to optimize the performance.
>
> I came across think this article: https://docs.
> datastax.com/en/cassandra/3.0/cassandra/operations/
> opsConfiguringCaches.html
>
> And it suggests not to even touch row cache unless read workload is > 95%
> and mostly rely on machine's default cache mechanism which comes with OS.
>
> The default row cache size is 0 in cassandra.yaml file so the row cache
> won't be utilized at all.
>
> Therefore, I'm wondering how exactly I can decide to chose to tweak row
> cache if needed. Are there any good pointers one can provide on this?
>
> Thanks,
> Preetika
>