You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Abhinav Solan <ab...@gmail.com> on 2016/10/01 01:20:26 UTC
Row cache not working
Hi Everyone,
My table looks like this -
CREATE TABLE test.reads (
svc_pt_id bigint,
meas_type_id bigint,
flags bigint,
read_time timestamp,
value double,
PRIMARY KEY ((svc_pt_id, meas_type_id))
) WITH bloom_filter_fp_chance = 0.1
AND caching = {'keys': 'ALL', 'rows_per_partition': '10'}
AND comment = ''
AND compaction = {'class':
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
AND compression = {'chunk_length_in_kb': '64', 'class':
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
Have set up the C* nodes with
row_cache_size_in_mb: 1024
row_cache_save_period: 14400
and I am making this query
select svc_pt_id, meas_type_id, read_time, value FROM
cts_svc_pt_latest_int_read where svc_pt_id = -9941235 and meas_type_id =
146;
with tracing on every time it says Row cache miss
activity
| timestamp | source | source_elapsed
-------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------+-----------------+----------------
Execute
CQL3 query | 2016-09-30 18:15:00.446000 | 192.168.199.75 | 0
Parsing select svc_pt_id, meas_type_id, read_time, value FROM
cts_svc_pt_latest_int_read where svc_pt_id = -9941235 and meas_type_id =
146; [SharedPool-Worker-1] | 2016-09-30 18:15:00.446000 | 192.168.199.75 |
111
Preparing statement
[SharedPool-Worker-1] | 2016-09-30 18:15:00.446000 | 192.168.199.75 |
209
reading data from /192.168.170.186
[SharedPool-Worker-1] | 2016-09-30 18:15:00.446001 | 192.168.199.75 |
370
Sending READ message to /192.168.170.186 [MessagingService-Outgoing-/
192.168.170.186] | 2016-09-30 18:15:00.446001 | 192.168.199.75 |
450
REQUEST_RESPONSE message received from /192.168.170.186
[MessagingService-Incoming-/192.168.170.186] | 2016-09-30 18:15:00.448000 |
192.168.199.75 | 2469
Processing response from /192.168.170.186
[SharedPool-Worker-8] | 2016-09-30 18:15:00.448000 | 192.168.199.75 |
2609
READ message received from /192.168.199.75 [MessagingService-Incoming-/
192.168.199.75] | 2016-09-30 18:15:00.449000 | 192.168.170.186 |
75
Row cache miss
[SharedPool-Worker-2] | 2016-09-30 18:15:00.449000 | 192.168.170.186 |
218
Fetching data but not
populating cache as query does not query from the start of the partition
[SharedPool-Worker-2] | 2016-09-30 18:15:00.449000 | 192.168.170.186 |
246
Executing single-partition query on cts_svc_pt_latest_int_read
[SharedPool-Worker-2] | 2016-09-30 18:15:00.449000 | 192.168.170.186 |
259
Acquiring sstable references
[SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 |
281
Merging memtable contents
[SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 |
295
Merging data from sstable 8
[SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 |
326
Key cache hit for sstable 8
[SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 |
351
Merging data from sstable 7
[SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 |
439
Key cache hit for sstable 7
[SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 |
468
Read 1 live and 0 tombstone cells
[SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 |
615
Enqueuing response to /192.168.199.75
[SharedPool-Worker-2] | 2016-09-30 18:15:00.449002 | 192.168.170.186 |
766
Sending
REQUEST_RESPONSE message to /192.168.199.75 [MessagingService-Outgoing-/
192.168.199.75] | 2016-09-30 18:15:00.449002 | 192.168.170.186 |
897
Request complete | 2016-09-30 18:15:00.448888 | 192.168.199.75 |
2888
Can please anyone tell me what I am doing wrong?
Thanks,
Abhinav
Re: Row cache not working
Posted by Jeff Jirsa <je...@crowdstrike.com>.
That’s true for versions 2.1 and newer. However, it’s possible that 3.0 engine rewrite introduced a bug or two that haven’t yet been found.
From: Hannu Kröger <hk...@gmail.com>
Reply-To: "user@cassandra.apache.org" <us...@cassandra.apache.org>
Date: Monday, October 3, 2016 at 3:52 PM
To: "user@cassandra.apache.org" <us...@cassandra.apache.org>
Subject: Re: Row cache not working
If I remember correctly row cache caches only N rows from the beginning of the partition. N being some configurable number.
See this link which is suggesting that:
http://www.datastax.com/dev/blog/row-caching-in-cassandra-2-1
Br,
Hannu
On 4 Oct 2016, at 1.32, Edward Capriolo <ed...@gmail.com> wrote:
Since the feature is off by default. The coverage might could be only as deep as the specific tests that test it.
On Mon, Oct 3, 2016 at 4:54 PM, Jeff Jirsa <je...@crowdstrike.com> wrote:
Seems like it’s probably worth opening a jira issue to track it (either to confirm it’s a bug, or to be able to better explain if/that it’s working as intended – the row cache is probably missing because trace indicates the read isn’t cacheable, but I suspect it should be cacheable).
Do note, though, that setting rows_per_partition to ALL can be very very very dangerous if you have very wide rows in any of your tables with row cache enabled.
From: Abhinav Solan <ab...@gmail.com>
Reply-To: "user@cassandra.apache.org" <us...@cassandra.apache.org>
Date: Monday, October 3, 2016 at 1:38 PM
To: "user@cassandra.apache.org" <us...@cassandra.apache.org>
Subject: Re: Row cache not working
It's cassandra 3.0.7,
I had to set caching = {'keys': 'ALL', 'rows_per_partition': 'ALL'}, then only it works don't know why.
If I set 'rows_per_partition':'1' then it does not work.
Also wanted to ask one thing, if I set row_cache_save_period: 60 then this cache would be refreshed automatically or it would be lazy, whenever the fetch call is made then only it caches it.
On Mon, Oct 3, 2016 at 1:31 PM Jeff Jirsa <je...@crowdstrike.com> wrote:
Which version of Cassandra are you running (I can tell it’s newer than 2.1, but exact version would be useful)?
From: Abhinav Solan <ab...@gmail.com>
Reply-To: "user@cassandra.apache.org" <us...@cassandra.apache.org>
Date: Monday, October 3, 2016 at 11:35 AM
To: "user@cassandra.apache.org" <us...@cassandra.apache.org>
Subject: Re: Row cache not working
Hi, can anyone please help me with this
Thanks,
Abhinav
On Fri, Sep 30, 2016 at 6:20 PM Abhinav Solan <ab...@gmail.com> wrote:
Hi Everyone,
My table looks like this -
CREATE TABLE test.reads (
svc_pt_id bigint,
meas_type_id bigint,
flags bigint,
read_time timestamp,
value double,
PRIMARY KEY ((svc_pt_id, meas_type_id))
) WITH bloom_filter_fp_chance = 0.1
AND caching = {'keys': 'ALL', 'rows_per_partition': '10'}
AND comment = ''
AND compaction = {'class': 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
Have set up the C* nodes with
row_cache_size_in_mb: 1024
row_cache_save_period: 14400
and I am making this query
select svc_pt_id, meas_type_id, read_time, value FROM cts_svc_pt_latest_int_read where svc_pt_id = -9941235 and meas_type_id = 146;
with tracing on every time it says Row cache miss
activity | timestamp | source | source_elapsed
-------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------+-----------------+----------------
Execute CQL3 query | 2016-09-30 18:15:00.446000 | 192.168.199.75 | 0
Parsing select svc_pt_id, meas_type_id, read_time, value FROM cts_svc_pt_latest_int_read where svc_pt_id = -9941235 and meas_type_id = 146; [SharedPool-Worker-1] | 2016-09-30 18:15:00.446000 | 192.168.199.75 | 111
Preparing statement [SharedPool-Worker-1] | 2016-09-30 18:15:00.446000 | 192.168.199.75 | 209
reading data from /192.168.170.186 [SharedPool-Worker-1] | 2016-09-30 18:15:00.446001 | 192.168.199.75 | 370
Sending READ message to /192.168.170.186 [MessagingService-Outgoing-/192.168.170.186] | 2016-09-30 18:15:00.446001 | 192.168.199.75 | 450
REQUEST_RESPONSE message received from /192.168.170.186 [MessagingService-Incoming-/192.168.170.186] | 2016-09-30 18:15:00.448000 | 192.168.199.75 | 2469
Processing response from /192.168.170.186 [SharedPool-Worker-8] | 2016-09-30 18:15:00.448000 | 192.168.199.75 | 2609
READ message received from /192.168.199.75 [MessagingService-Incoming-/192.168.199.75] | 2016-09-30 18:15:00.449000 | 192.168.170.186 | 75
Row cache miss [SharedPool-Worker-2] | 2016-09-30 18:15:00.449000 | 192.168.170.186 | 218
Fetching data but not populating cache as query does not query from the start of the partition [SharedPool-Worker-2] | 2016-09-30 18:15:00.449000 | 192.168.170.186 | 246
Executing single-partition query on cts_svc_pt_latest_int_read [SharedPool-Worker-2] | 2016-09-30 18:15:00.449000 | 192.168.170.186 | 259
Acquiring sstable references [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 | 281
Merging memtable contents [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 | 295
Merging data from sstable 8 [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 | 326
Key cache hit for sstable 8 [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 | 351
Merging data from sstable 7 [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 | 439
Key cache hit for sstable 7 [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 | 468
Read 1 live and 0 tombstone cells [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 | 615
Enqueuing response to /192.168.199.75 [SharedPool-Worker-2] | 2016-09-30 18:15:00.449002 | 192.168.170.186 | 766
Sending REQUEST_RESPONSE message to /192.168.199.75 [MessagingService-Outgoing-/192.168.199.75] | 2016-09-30 18:15:00.449002 | 192.168.170.186 | 897
Request complete | 2016-09-30 18:15:00.448888 | 192.168.199.75 | 2888
Can please anyone tell me what I am doing wrong?
Thanks,
Abhinav
____________________________________________________________________
CONFIDENTIALITY NOTE: This e-mail and any attachments are confidential and may be legally privileged. If you are not the intended recipient, do not disclose, copy, distribute, or use this email or any attachments. If you have received this in error please let the sender know and then delete the email and all attachments.
____________________________________________________________________
CONFIDENTIALITY NOTE: This e-mail and any attachments are confidential and may be legally privileged. If you are not the intended recipient, do not disclose, copy, distribute, or use this email or any attachments. If you have received this in error please let the sender know and then delete the email and all attachments.
____________________________________________________________________
CONFIDENTIALITY NOTE: This e-mail and any attachments are confidential and may be legally privileged. If you are not the intended recipient, do not disclose, copy, distribute, or use this email or any attachments. If you have received this in error please let the sender know and then delete the email and all attachments.
Re: Row cache not working
Posted by Hannu Kröger <hk...@gmail.com>.
If I remember correctly row cache caches only N rows from the beginning of the partition. N being some configurable number.
See this link which is suggesting that:
http://www.datastax.com/dev/blog/row-caching-in-cassandra-2-1
Br,
Hannu
> On 4 Oct 2016, at 1.32, Edward Capriolo <ed...@gmail.com> wrote:
>
> Since the feature is off by default. The coverage might could be only as deep as the specific tests that test it.
>
>> On Mon, Oct 3, 2016 at 4:54 PM, Jeff Jirsa <je...@crowdstrike.com> wrote:
>> Seems like it’s probably worth opening a jira issue to track it (either to confirm it’s a bug, or to be able to better explain if/that it’s working as intended – the row cache is probably missing because trace indicates the read isn’t cacheable, but I suspect it should be cacheable).
>>
>>
>>
>> Do note, though, that setting rows_per_partition to ALL can be very very very dangerous if you have very wide rows in any of your tables with row cache enabled.
>>
>>
>>
>>
>>
>>
>>
>> From: Abhinav Solan <ab...@gmail.com>
>> Reply-To: "user@cassandra.apache.org" <us...@cassandra.apache.org>
>> Date: Monday, October 3, 2016 at 1:38 PM
>> To: "user@cassandra.apache.org" <us...@cassandra.apache.org>
>> Subject: Re: Row cache not working
>>
>>
>>
>> It's cassandra 3.0.7,
>>
>> I had to set caching = {'keys': 'ALL', 'rows_per_partition': 'ALL'}, then only it works don't know why.
>>
>> If I set 'rows_per_partition':'1' then it does not work.
>>
>>
>>
>> Also wanted to ask one thing, if I set row_cache_save_period: 60 then this cache would be refreshed automatically or it would be lazy, whenever the fetch call is made then only it caches it.
>>
>>
>>
>> On Mon, Oct 3, 2016 at 1:31 PM Jeff Jirsa <je...@crowdstrike.com> wrote:
>>
>> Which version of Cassandra are you running (I can tell it’s newer than 2.1, but exact version would be useful)?
>>
>>
>>
>> From: Abhinav Solan <ab...@gmail.com>
>> Reply-To: "user@cassandra.apache.org" <us...@cassandra.apache.org>
>> Date: Monday, October 3, 2016 at 11:35 AM
>> To: "user@cassandra.apache.org" <us...@cassandra.apache.org>
>> Subject: Re: Row cache not working
>>
>>
>>
>> Hi, can anyone please help me with this
>>
>>
>>
>> Thanks,
>>
>> Abhinav
>>
>>
>>
>> On Fri, Sep 30, 2016 at 6:20 PM Abhinav Solan <ab...@gmail.com> wrote:
>>
>> Hi Everyone,
>>
>>
>>
>> My table looks like this -
>>
>> CREATE TABLE test.reads (
>>
>> svc_pt_id bigint,
>>
>> meas_type_id bigint,
>>
>> flags bigint,
>>
>> read_time timestamp,
>>
>> value double,
>>
>> PRIMARY KEY ((svc_pt_id, meas_type_id))
>>
>> ) WITH bloom_filter_fp_chance = 0.1
>>
>> AND caching = {'keys': 'ALL', 'rows_per_partition': '10'}
>>
>> AND comment = ''
>>
>> AND compaction = {'class': 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
>>
>> AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
>>
>> AND crc_check_chance = 1.0
>>
>> AND dclocal_read_repair_chance = 0.1
>>
>> AND default_time_to_live = 0
>>
>> AND gc_grace_seconds = 864000
>>
>> AND max_index_interval = 2048
>>
>> AND memtable_flush_period_in_ms = 0
>>
>> AND min_index_interval = 128
>>
>> AND read_repair_chance = 0.0
>>
>> AND speculative_retry = '99PERCENTILE';
>>
>>
>>
>> Have set up the C* nodes with
>>
>> row_cache_size_in_mb: 1024
>>
>> row_cache_save_period: 14400
>>
>>
>>
>> and I am making this query
>>
>> select svc_pt_id, meas_type_id, read_time, value FROM cts_svc_pt_latest_int_read where svc_pt_id = -9941235 and meas_type_id = 146;
>>
>>
>>
>> with tracing on every time it says Row cache miss
>>
>>
>>
>> activity | timestamp | source | source_elapsed
>>
>> -------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------+-----------------+----------------
>>
>> Execute CQL3 query | 2016-09-30 18:15:00.446000 | 192.168.199.75 | 0
>>
>> Parsing select svc_pt_id, meas_type_id, read_time, value FROM cts_svc_pt_latest_int_read where svc_pt_id = -9941235 and meas_type_id = 146; [SharedPool-Worker-1] | 2016-09-30 18:15:00.446000 | 192.168.199.75 | 111
>>
>> Preparing statement [SharedPool-Worker-1] | 2016-09-30 18:15:00.446000 | 192.168.199.75 | 209
>>
>> reading data from /192.168.170.186 [SharedPool-Worker-1] | 2016-09-30 18:15:00.446001 | 192.168.199.75 | 370
>>
>> Sending READ message to /192.168.170.186 [MessagingService-Outgoing-/192.168.170.186] | 2016-09-30 18:15:00.446001 | 192.168.199.75 | 450
>>
>> REQUEST_RESPONSE message received from /192.168.170.186 [MessagingService-Incoming-/192.168.170.186] | 2016-09-30 18:15:00.448000 | 192.168.199.75 | 2469
>>
>> Processing response from /192.168.170.186 [SharedPool-Worker-8] | 2016-09-30 18:15:00.448000 | 192.168.199.75 | 2609
>>
>> READ message received from /192.168.199.75 [MessagingService-Incoming-/192.168.199.75] | 2016-09-30 18:15:00.449000 | 192.168.170.186 | 75
>>
>> Row cache miss [SharedPool-Worker-2] | 2016-09-30 18:15:00.449000 | 192.168.170.186 | 218
>>
>> Fetching data but not populating cache as query does not query from the start of the partition [SharedPool-Worker-2] | 2016-09-30 18:15:00.449000 | 192.168.170.186 | 246
>>
>> Executing single-partition query on cts_svc_pt_latest_int_read [SharedPool-Worker-2] | 2016-09-30 18:15:00.449000 | 192.168.170.186 | 259
>>
>> Acquiring sstable references [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 | 281
>>
>> Merging memtable contents [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 | 295
>>
>> Merging data from sstable 8 [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 | 326
>>
>> Key cache hit for sstable 8 [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 | 351
>>
>> Merging data from sstable 7 [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 | 439
>>
>> Key cache hit for sstable 7 [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 | 468
>>
>> Read 1 live and 0 tombstone cells [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 | 615
>>
>> Enqueuing response to /192.168.199.75 [SharedPool-Worker-2] | 2016-09-30 18:15:00.449002 | 192.168.170.186 | 766
>>
>> Sending REQUEST_RESPONSE message to /192.168.199.75 [MessagingService-Outgoing-/192.168.199.75] | 2016-09-30 18:15:00.449002 | 192.168.170.186 | 897
>>
>> Request complete | 2016-09-30 18:15:00.448888 | 192.168.199.75 | 2888
>>
>>
>>
>> Can please anyone tell me what I am doing wrong?
>>
>>
>>
>> Thanks,
>>
>> Abhinav
>>
>> ____________________________________________________________________
>> CONFIDENTIALITY NOTE: This e-mail and any attachments are confidential and may be legally privileged. If you are not the intended recipient, do not disclose, copy, distribute, or use this email or any attachments. If you have received this in error please let the sender know and then delete the email and all attachments.
>>
>> ____________________________________________________________________
>> CONFIDENTIALITY NOTE: This e-mail and any attachments are confidential and may be legally privileged. If you are not the intended recipient, do not disclose, copy, distribute, or use this email or any attachments. If you have received this in error please let the sender know and then delete the email and all attachments.
>
Re: Row cache not working
Posted by Edward Capriolo <ed...@gmail.com>.
Since the feature is off by default. The coverage might could be only as
deep as the specific tests that test it.
On Mon, Oct 3, 2016 at 4:54 PM, Jeff Jirsa <je...@crowdstrike.com>
wrote:
> Seems like it’s probably worth opening a jira issue to track it (either to
> confirm it’s a bug, or to be able to better explain if/that it’s working as
> intended – the row cache is probably missing because trace indicates the
> read isn’t cacheable, but I suspect it should be cacheable).
>
>
>
>
>
>
> Do note, though, that setting rows_per_partition to ALL can be very very
> very dangerous if you have very wide rows in any of your tables with row
> cache enabled.
>
>
>
>
>
>
>
> *From: *Abhinav Solan <ab...@gmail.com>
> *Reply-To: *"user@cassandra.apache.org" <us...@cassandra.apache.org>
> *Date: *Monday, October 3, 2016 at 1:38 PM
> *To: *"user@cassandra.apache.org" <us...@cassandra.apache.org>
> *Subject: *Re: Row cache not working
>
>
>
> It's cassandra 3.0.7,
>
> I had to set caching = {'keys': 'ALL', 'rows_per_partition': 'ALL'}, then
> only it works don't know why.
>
> If I set 'rows_per_partition':'1' then it does not work.
>
>
>
> Also wanted to ask one thing, if I set row_cache_save_period: 60 then this
> cache would be refreshed automatically or it would be lazy, whenever the
> fetch call is made then only it caches it.
>
>
>
> On Mon, Oct 3, 2016 at 1:31 PM Jeff Jirsa <je...@crowdstrike.com>
> wrote:
>
> Which version of Cassandra are you running (I can tell it’s newer than
> 2.1, but exact version would be useful)?
>
>
>
> *From: *Abhinav Solan <ab...@gmail.com>
> *Reply-To: *"user@cassandra.apache.org" <us...@cassandra.apache.org>
> *Date: *Monday, October 3, 2016 at 11:35 AM
> *To: *"user@cassandra.apache.org" <us...@cassandra.apache.org>
> *Subject: *Re: Row cache not working
>
>
>
> Hi, can anyone please help me with this
>
>
>
> Thanks,
>
> Abhinav
>
>
>
> On Fri, Sep 30, 2016 at 6:20 PM Abhinav Solan <ab...@gmail.com>
> wrote:
>
> Hi Everyone,
>
>
>
> My table looks like this -
>
> CREATE TABLE test.reads (
>
> svc_pt_id bigint,
>
> meas_type_id bigint,
>
> flags bigint,
>
> read_time timestamp,
>
> value double,
>
> PRIMARY KEY ((svc_pt_id, meas_type_id))
>
> ) WITH bloom_filter_fp_chance = 0.1
>
> AND caching = {'keys': 'ALL', 'rows_per_partition': '10'}
>
> AND comment = ''
>
> AND compaction = {'class': 'org.apache.cassandra.db.compaction.
> LeveledCompactionStrategy'}
>
> AND compression = {'chunk_length_in_kb': '64', 'class': '
> org.apache.cassandra.io.compress.LZ4Compressor'}
>
> AND crc_check_chance = 1.0
>
> AND dclocal_read_repair_chance = 0.1
>
> AND default_time_to_live = 0
>
> AND gc_grace_seconds = 864000
>
> AND max_index_interval = 2048
>
> AND memtable_flush_period_in_ms = 0
>
> AND min_index_interval = 128
>
> AND read_repair_chance = 0.0
>
> AND speculative_retry = '99PERCENTILE';
>
>
>
> Have set up the C* nodes with
>
> row_cache_size_in_mb: 1024
>
> row_cache_save_period: 14400
>
>
>
> and I am making this query
>
> select svc_pt_id, meas_type_id, read_time, value FROM
> cts_svc_pt_latest_int_read where svc_pt_id = -9941235 and meas_type_id =
> 146;
>
>
>
> with tracing on every time it says Row cache miss
>
>
>
> activity
>
> | timestamp | source | source_elapsed
>
> ------------------------------------------------------------
> ------------------------------------------------------------
> -------------------------------------------+----------------
> ------------+-----------------+----------------
>
>
>
> Execute CQL3 query | 2016-09-30 18:15:00.446000 | 192.168.199.75 |
> 0
>
> Parsing select svc_pt_id, meas_type_id, read_time, value FROM
> cts_svc_pt_latest_int_read where svc_pt_id = -9941235 and meas_type_id =
> 146; [SharedPool-Worker-1] | 2016-09-30 18:15:00.446000 | 192.168.199.75 |
> 111
>
>
> Preparing statement
> [SharedPool-Worker-1] | 2016-09-30 18:15:00.446000 | 192.168.199.75 |
> 209
>
>
> reading data from /192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQMGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> [SharedPool-Worker-1] | 2016-09-30 18:15:00.446001 | 192.168.199.75 |
> 370
>
>
> Sending READ message to /192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQMGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> [MessagingService-Outgoing-/192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQMGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>]
> | 2016-09-30 18:15:00.446001 | 192.168.199.75 | 450
>
>
> REQUEST_RESPONSE message received from /192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQMGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> [MessagingService-Incoming-/192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQMGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>]
> | 2016-09-30 18:15:00.448000 | 192.168.199.75 | 2469
>
>
> Processing response from /192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQMGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> [SharedPool-Worker-8] | 2016-09-30 18:15:00.448000 | 192.168.199.75 |
> 2609
>
>
> READ message received from /192.168.199.75
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.199.75&d=DQMGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=h3vrg21r2ONFL5xKVRHMIzK3hYMVlqoOpJjKecKhjU8&e=>
> [MessagingService-Incoming-/192.168.199.75
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.199.75&d=DQMGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=h3vrg21r2ONFL5xKVRHMIzK3hYMVlqoOpJjKecKhjU8&e=>]
> | 2016-09-30 18:15:00.449000 | 192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQQGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> | 75
>
>
> Row cache miss
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449000 | 192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQQGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> | 218
>
> Fetching data but not
> populating cache as query does not query from the start of the partition
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449000 | 192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQQGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> | 246
>
>
> Executing single-partition query on cts_svc_pt_latest_int_read
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449000 | 192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQQGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> | 259
>
>
> Acquiring sstable references
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQQGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> | 281
>
>
> Merging memtable contents
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQQGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> | 295
>
>
> Merging data from sstable 8
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQQGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> | 326
>
>
> Key cache hit for sstable 8
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQQGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> | 351
>
>
> Merging data from sstable 7
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQQGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> | 439
>
>
> Key cache hit for sstable 7
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQQGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> | 468
>
>
> Read 1 live and 0 tombstone cells
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQQGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> | 615
>
>
> Enqueuing response to /192.168.199.75
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.199.75&d=DQMGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=h3vrg21r2ONFL5xKVRHMIzK3hYMVlqoOpJjKecKhjU8&e=>
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449002 | 192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQQGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> | 766
>
> Sending
> REQUEST_RESPONSE message to /192.168.199.75
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.199.75&d=DQMGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=h3vrg21r2ONFL5xKVRHMIzK3hYMVlqoOpJjKecKhjU8&e=>
> [MessagingService-Outgoing-/192.168.199.75
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.199.75&d=DQMGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=h3vrg21r2ONFL5xKVRHMIzK3hYMVlqoOpJjKecKhjU8&e=>]
> | 2016-09-30 18:15:00.449002 | 192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQQGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> | 897
>
>
>
> Request complete | 2016-09-30 18:15:00.448888 | 192.168.199.75 |
> 2888
>
>
>
> Can please anyone tell me what I am doing wrong?
>
>
>
> Thanks,
>
> Abhinav
>
> ____________________________________________________________________
> CONFIDENTIALITY NOTE: This e-mail and any attachments are confidential and
> may be legally privileged. If you are not the intended recipient, do not
> disclose, copy, distribute, or use this email or any attachments. If you
> have received this in error please let the sender know and then delete the
> email and all attachments.
>
> ____________________________________________________________________
> CONFIDENTIALITY NOTE: This e-mail and any attachments are confidential and
> may be legally privileged. If you are not the intended recipient, do not
> disclose, copy, distribute, or use this email or any attachments. If you
> have received this in error please let the sender know and then delete the
> email and all attachments.
>
Re: Row cache not working
Posted by Jeff Jirsa <je...@crowdstrike.com>.
Seems like it’s probably worth opening a jira issue to track it (either to confirm it’s a bug, or to be able to better explain if/that it’s working as intended – the row cache is probably missing because trace indicates the read isn’t cacheable, but I suspect it should be cacheable).
Do note, though, that setting rows_per_partition to ALL can be very very very dangerous if you have very wide rows in any of your tables with row cache enabled.
From: Abhinav Solan <ab...@gmail.com>
Reply-To: "user@cassandra.apache.org" <us...@cassandra.apache.org>
Date: Monday, October 3, 2016 at 1:38 PM
To: "user@cassandra.apache.org" <us...@cassandra.apache.org>
Subject: Re: Row cache not working
It's cassandra 3.0.7,
I had to set caching = {'keys': 'ALL', 'rows_per_partition': 'ALL'}, then only it works don't know why.
If I set 'rows_per_partition':'1' then it does not work.
Also wanted to ask one thing, if I set row_cache_save_period: 60 then this cache would be refreshed automatically or it would be lazy, whenever the fetch call is made then only it caches it.
On Mon, Oct 3, 2016 at 1:31 PM Jeff Jirsa <je...@crowdstrike.com> wrote:
Which version of Cassandra are you running (I can tell it’s newer than 2.1, but exact version would be useful)?
From: Abhinav Solan <ab...@gmail.com>
Reply-To: "user@cassandra.apache.org" <us...@cassandra.apache.org>
Date: Monday, October 3, 2016 at 11:35 AM
To: "user@cassandra.apache.org" <us...@cassandra.apache.org>
Subject: Re: Row cache not working
Hi, can anyone please help me with this
Thanks,
Abhinav
On Fri, Sep 30, 2016 at 6:20 PM Abhinav Solan <ab...@gmail.com> wrote:
Hi Everyone,
My table looks like this -
CREATE TABLE test.reads (
svc_pt_id bigint,
meas_type_id bigint,
flags bigint,
read_time timestamp,
value double,
PRIMARY KEY ((svc_pt_id, meas_type_id))
) WITH bloom_filter_fp_chance = 0.1
AND caching = {'keys': 'ALL', 'rows_per_partition': '10'}
AND comment = ''
AND compaction = {'class': 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
Have set up the C* nodes with
row_cache_size_in_mb: 1024
row_cache_save_period: 14400
and I am making this query
select svc_pt_id, meas_type_id, read_time, value FROM cts_svc_pt_latest_int_read where svc_pt_id = -9941235 and meas_type_id = 146;
with tracing on every time it says Row cache miss
activity | timestamp | source | source_elapsed
-------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------+-----------------+----------------
Execute CQL3 query | 2016-09-30 18:15:00.446000 | 192.168.199.75 | 0
Parsing select svc_pt_id, meas_type_id, read_time, value FROM cts_svc_pt_latest_int_read where svc_pt_id = -9941235 and meas_type_id = 146; [SharedPool-Worker-1] | 2016-09-30 18:15:00.446000 | 192.168.199.75 | 111
Preparing statement [SharedPool-Worker-1] | 2016-09-30 18:15:00.446000 | 192.168.199.75 | 209
reading data from /192.168.170.186 [SharedPool-Worker-1] | 2016-09-30 18:15:00.446001 | 192.168.199.75 | 370
Sending READ message to /192.168.170.186 [MessagingService-Outgoing-/192.168.170.186] | 2016-09-30 18:15:00.446001 | 192.168.199.75 | 450
REQUEST_RESPONSE message received from /192.168.170.186 [MessagingService-Incoming-/192.168.170.186] | 2016-09-30 18:15:00.448000 | 192.168.199.75 | 2469
Processing response from /192.168.170.186 [SharedPool-Worker-8] | 2016-09-30 18:15:00.448000 | 192.168.199.75 | 2609
READ message received from /192.168.199.75 [MessagingService-Incoming-/192.168.199.75] | 2016-09-30 18:15:00.449000 | 192.168.170.186 | 75
Row cache miss [SharedPool-Worker-2] | 2016-09-30 18:15:00.449000 | 192.168.170.186 | 218
Fetching data but not populating cache as query does not query from the start of the partition [SharedPool-Worker-2] | 2016-09-30 18:15:00.449000 | 192.168.170.186 | 246
Executing single-partition query on cts_svc_pt_latest_int_read [SharedPool-Worker-2] | 2016-09-30 18:15:00.449000 | 192.168.170.186 | 259
Acquiring sstable references [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 | 281
Merging memtable contents [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 | 295
Merging data from sstable 8 [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 | 326
Key cache hit for sstable 8 [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 | 351
Merging data from sstable 7 [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 | 439
Key cache hit for sstable 7 [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 | 468
Read 1 live and 0 tombstone cells [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 | 615
Enqueuing response to /192.168.199.75 [SharedPool-Worker-2] | 2016-09-30 18:15:00.449002 | 192.168.170.186 | 766
Sending REQUEST_RESPONSE message to /192.168.199.75 [MessagingService-Outgoing-/192.168.199.75] | 2016-09-30 18:15:00.449002 | 192.168.170.186 | 897
Request complete | 2016-09-30 18:15:00.448888 | 192.168.199.75 | 2888
Can please anyone tell me what I am doing wrong?
Thanks,
Abhinav
____________________________________________________________________
CONFIDENTIALITY NOTE: This e-mail and any attachments are confidential and may be legally privileged. If you are not the intended recipient, do not disclose, copy, distribute, or use this email or any attachments. If you have received this in error please let the sender know and then delete the email and all attachments.
____________________________________________________________________
CONFIDENTIALITY NOTE: This e-mail and any attachments are confidential and may be legally privileged. If you are not the intended recipient, do not disclose, copy, distribute, or use this email or any attachments. If you have received this in error please let the sender know and then delete the email and all attachments.
Re: Row cache not working
Posted by Abhinav Solan <ab...@gmail.com>.
It's cassandra 3.0.7,
I had to set caching = {'keys': 'ALL', 'rows_per_partition': 'ALL'}, then
only it works don't know why.
If I set 'rows_per_partition':'1' then it does not work.
Also wanted to ask one thing, if I set row_cache_save_period: 60 then this
cache would be refreshed automatically or it would be lazy, whenever the
fetch call is made then only it caches it.
On Mon, Oct 3, 2016 at 1:31 PM Jeff Jirsa <je...@crowdstrike.com>
wrote:
> Which version of Cassandra are you running (I can tell it’s newer than
> 2.1, but exact version would be useful)?
>
>
>
> *From: *Abhinav Solan <ab...@gmail.com>
> *Reply-To: *"user@cassandra.apache.org" <us...@cassandra.apache.org>
> *Date: *Monday, October 3, 2016 at 11:35 AM
> *To: *"user@cassandra.apache.org" <us...@cassandra.apache.org>
> *Subject: *Re: Row cache not working
>
>
>
> Hi, can anyone please help me with this
>
>
>
> Thanks,
>
> Abhinav
>
>
>
> On Fri, Sep 30, 2016 at 6:20 PM Abhinav Solan <ab...@gmail.com>
> wrote:
>
> Hi Everyone,
>
>
>
> My table looks like this -
>
> CREATE TABLE test.reads (
>
> svc_pt_id bigint,
>
> meas_type_id bigint,
>
> flags bigint,
>
> read_time timestamp,
>
> value double,
>
> PRIMARY KEY ((svc_pt_id, meas_type_id))
>
> ) WITH bloom_filter_fp_chance = 0.1
>
> AND caching = {'keys': 'ALL', 'rows_per_partition': '10'}
>
> AND comment = ''
>
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
>
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
>
> AND crc_check_chance = 1.0
>
> AND dclocal_read_repair_chance = 0.1
>
> AND default_time_to_live = 0
>
> AND gc_grace_seconds = 864000
>
> AND max_index_interval = 2048
>
> AND memtable_flush_period_in_ms = 0
>
> AND min_index_interval = 128
>
> AND read_repair_chance = 0.0
>
> AND speculative_retry = '99PERCENTILE';
>
>
>
> Have set up the C* nodes with
>
> row_cache_size_in_mb: 1024
>
> row_cache_save_period: 14400
>
>
>
> and I am making this query
>
> select svc_pt_id, meas_type_id, read_time, value FROM
> cts_svc_pt_latest_int_read where svc_pt_id = -9941235 and meas_type_id =
> 146;
>
>
>
> with tracing on every time it says Row cache miss
>
>
>
> activity
>
> | timestamp | source | source_elapsed
>
>
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------+-----------------+----------------
>
>
>
> Execute CQL3 query | 2016-09-30 18:15:00.446000 | 192.168.199.75 |
> 0
>
> Parsing select svc_pt_id, meas_type_id, read_time, value FROM
> cts_svc_pt_latest_int_read where svc_pt_id = -9941235 and meas_type_id =
> 146; [SharedPool-Worker-1] | 2016-09-30 18:15:00.446000 | 192.168.199.75 |
> 111
>
>
> Preparing statement
> [SharedPool-Worker-1] | 2016-09-30 18:15:00.446000 | 192.168.199.75 |
> 209
>
>
> reading data from /192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQMGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> [SharedPool-Worker-1] | 2016-09-30 18:15:00.446001 | 192.168.199.75 |
> 370
>
>
> Sending READ message to /192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQMGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> [MessagingService-Outgoing-/192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQMGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>]
> | 2016-09-30 18:15:00.446001 | 192.168.199.75 | 450
>
>
> REQUEST_RESPONSE message received from /192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQMGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> [MessagingService-Incoming-/192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQMGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>]
> | 2016-09-30 18:15:00.448000 | 192.168.199.75 | 2469
>
>
> Processing response from /192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQMGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> [SharedPool-Worker-8] | 2016-09-30 18:15:00.448000 | 192.168.199.75 |
> 2609
>
>
> READ message received from /192.168.199.75
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.199.75&d=DQMGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=h3vrg21r2ONFL5xKVRHMIzK3hYMVlqoOpJjKecKhjU8&e=>
> [MessagingService-Incoming-/192.168.199.75
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.199.75&d=DQMGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=h3vrg21r2ONFL5xKVRHMIzK3hYMVlqoOpJjKecKhjU8&e=>]
> | 2016-09-30 18:15:00.449000 | 192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQQGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> | 75
>
>
> Row cache miss
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449000 | 192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQQGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> | 218
>
> Fetching data but not
> populating cache as query does not query from the start of the partition
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449000 | 192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQQGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> | 246
>
>
> Executing single-partition query on cts_svc_pt_latest_int_read
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449000 | 192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQQGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> | 259
>
>
> Acquiring sstable references
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQQGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> | 281
>
>
> Merging memtable contents
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQQGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> | 295
>
>
> Merging data from sstable 8
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQQGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> | 326
>
>
> Key cache hit for sstable 8
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQQGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> | 351
>
>
> Merging data from sstable 7
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQQGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> | 439
>
>
> Key cache hit for sstable 7
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQQGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> | 468
>
>
> Read 1 live and 0 tombstone cells
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQQGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> | 615
>
>
> Enqueuing response to /192.168.199.75
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.199.75&d=DQMGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=h3vrg21r2ONFL5xKVRHMIzK3hYMVlqoOpJjKecKhjU8&e=>
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449002 | 192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQQGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> | 766
>
> Sending
> REQUEST_RESPONSE message to /192.168.199.75
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.199.75&d=DQMGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=h3vrg21r2ONFL5xKVRHMIzK3hYMVlqoOpJjKecKhjU8&e=>
> [MessagingService-Outgoing-/192.168.199.75
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.199.75&d=DQMGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=h3vrg21r2ONFL5xKVRHMIzK3hYMVlqoOpJjKecKhjU8&e=>]
> | 2016-09-30 18:15:00.449002 | 192.168.170.186
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.170.186&d=DQQGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=TzZ71ThTYrI2Cs7eYc2nhu4gOJpHM6B89KY97yj0Pp4&s=Rsg4cca5QVAWlI6cS1M673hWQ66Jxg2B5zK-HoJ6ZlQ&e=>
> | 897
>
>
>
> Request complete | 2016-09-30 18:15:00.448888 | 192.168.199.75 |
> 2888
>
>
>
> Can please anyone tell me what I am doing wrong?
>
>
>
> Thanks,
>
> Abhinav
>
> ____________________________________________________________________
> CONFIDENTIALITY NOTE: This e-mail and any attachments are confidential and
> may be legally privileged. If you are not the intended recipient, do not
> disclose, copy, distribute, or use this email or any attachments. If you
> have received this in error please let the sender know and then delete the
> email and all attachments.
>
Re: Row cache not working
Posted by Jeff Jirsa <je...@crowdstrike.com>.
Which version of Cassandra are you running (I can tell it’s newer than 2.1, but exact version would be useful)?
From: Abhinav Solan <ab...@gmail.com>
Reply-To: "user@cassandra.apache.org" <us...@cassandra.apache.org>
Date: Monday, October 3, 2016 at 11:35 AM
To: "user@cassandra.apache.org" <us...@cassandra.apache.org>
Subject: Re: Row cache not working
Hi, can anyone please help me with this
Thanks,
Abhinav
On Fri, Sep 30, 2016 at 6:20 PM Abhinav Solan <ab...@gmail.com> wrote:
Hi Everyone,
My table looks like this -
CREATE TABLE test.reads (
svc_pt_id bigint,
meas_type_id bigint,
flags bigint,
read_time timestamp,
value double,
PRIMARY KEY ((svc_pt_id, meas_type_id))
) WITH bloom_filter_fp_chance = 0.1
AND caching = {'keys': 'ALL', 'rows_per_partition': '10'}
AND comment = ''
AND compaction = {'class': 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
Have set up the C* nodes with
row_cache_size_in_mb: 1024
row_cache_save_period: 14400
and I am making this query
select svc_pt_id, meas_type_id, read_time, value FROM cts_svc_pt_latest_int_read where svc_pt_id = -9941235 and meas_type_id = 146;
with tracing on every time it says Row cache miss
activity | timestamp | source | source_elapsed
-------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------+-----------------+----------------
Execute CQL3 query | 2016-09-30 18:15:00.446000 | 192.168.199.75 | 0
Parsing select svc_pt_id, meas_type_id, read_time, value FROM cts_svc_pt_latest_int_read where svc_pt_id = -9941235 and meas_type_id = 146; [SharedPool-Worker-1] | 2016-09-30 18:15:00.446000 | 192.168.199.75 | 111
Preparing statement [SharedPool-Worker-1] | 2016-09-30 18:15:00.446000 | 192.168.199.75 | 209
reading data from /192.168.170.186 [SharedPool-Worker-1] | 2016-09-30 18:15:00.446001 | 192.168.199.75 | 370
Sending READ message to /192.168.170.186 [MessagingService-Outgoing-/192.168.170.186] | 2016-09-30 18:15:00.446001 | 192.168.199.75 | 450
REQUEST_RESPONSE message received from /192.168.170.186 [MessagingService-Incoming-/192.168.170.186] | 2016-09-30 18:15:00.448000 | 192.168.199.75 | 2469
Processing response from /192.168.170.186 [SharedPool-Worker-8] | 2016-09-30 18:15:00.448000 | 192.168.199.75 | 2609
READ message received from /192.168.199.75 [MessagingService-Incoming-/192.168.199.75] | 2016-09-30 18:15:00.449000 | 192.168.170.186 | 75
Row cache miss [SharedPool-Worker-2] | 2016-09-30 18:15:00.449000 | 192.168.170.186 | 218
Fetching data but not populating cache as query does not query from the start of the partition [SharedPool-Worker-2] | 2016-09-30 18:15:00.449000 | 192.168.170.186 | 246
Executing single-partition query on cts_svc_pt_latest_int_read [SharedPool-Worker-2] | 2016-09-30 18:15:00.449000 | 192.168.170.186 | 259
Acquiring sstable references [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 | 281
Merging memtable contents [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 | 295
Merging data from sstable 8 [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 | 326
Key cache hit for sstable 8 [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 | 351
Merging data from sstable 7 [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 | 439
Key cache hit for sstable 7 [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 | 468
Read 1 live and 0 tombstone cells [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 | 615
Enqueuing response to /192.168.199.75 [SharedPool-Worker-2] | 2016-09-30 18:15:00.449002 | 192.168.170.186 | 766
Sending REQUEST_RESPONSE message to /192.168.199.75 [MessagingService-Outgoing-/192.168.199.75] | 2016-09-30 18:15:00.449002 | 192.168.170.186 | 897
Request complete | 2016-09-30 18:15:00.448888 | 192.168.199.75 | 2888
Can please anyone tell me what I am doing wrong?
Thanks,
Abhinav
____________________________________________________________________
CONFIDENTIALITY NOTE: This e-mail and any attachments are confidential and may be legally privileged. If you are not the intended recipient, do not disclose, copy, distribute, or use this email or any attachments. If you have received this in error please let the sender know and then delete the email and all attachments.
Re: Row cache not working
Posted by Edward Capriolo <ed...@gmail.com>.
I was thinking about this issue. I was wondering on the dev side if it
would make sense to make a utility for the unit tests that could enable
tracing and then assert that a number of steps in the trace happened.
Something like:
setup()
runQuery("SELECT * FROM X")
Assertion.assertTrace("Preparing statement").then("Row cache
hit").then("Request complete");
This would be a pretty awesome way to verify things without mock/mockito.
On Mon, Oct 3, 2016 at 2:35 PM, Abhinav Solan <ab...@gmail.com>
wrote:
> Hi, can anyone please help me with this
>
> Thanks,
> Abhinav
>
> On Fri, Sep 30, 2016 at 6:20 PM Abhinav Solan <ab...@gmail.com>
> wrote:
>
>> Hi Everyone,
>>
>> My table looks like this -
>> CREATE TABLE test.reads (
>> svc_pt_id bigint,
>> meas_type_id bigint,
>> flags bigint,
>> read_time timestamp,
>> value double,
>> PRIMARY KEY ((svc_pt_id, meas_type_id))
>> ) WITH bloom_filter_fp_chance = 0.1
>> AND caching = {'keys': 'ALL', 'rows_per_partition': '10'}
>> AND comment = ''
>> AND compaction = {'class': 'org.apache.cassandra.db.compaction.
>> LeveledCompactionStrategy'}
>> AND compression = {'chunk_length_in_kb': '64', 'class': '
>> org.apache.cassandra.io.compress.LZ4Compressor'}
>> AND crc_check_chance = 1.0
>> AND dclocal_read_repair_chance = 0.1
>> AND default_time_to_live = 0
>> AND gc_grace_seconds = 864000
>> AND max_index_interval = 2048
>> AND memtable_flush_period_in_ms = 0
>> AND min_index_interval = 128
>> AND read_repair_chance = 0.0
>> AND speculative_retry = '99PERCENTILE';
>>
>> Have set up the C* nodes with
>> row_cache_size_in_mb: 1024
>> row_cache_save_period: 14400
>>
>> and I am making this query
>> select svc_pt_id, meas_type_id, read_time, value FROM
>> cts_svc_pt_latest_int_read where svc_pt_id = -9941235 and meas_type_id =
>> 146;
>>
>> with tracing on every time it says Row cache miss
>>
>> activity
>>
>> | timestamp | source | source_elapsed
>> ------------------------------------------------------------
>> ------------------------------------------------------------
>> -------------------------------------------+----------------
>> ------------+-----------------+----------------
>>
>>
>> Execute CQL3 query | 2016-09-30 18:15:00.446000 | 192.168.199.75 |
>> 0
>> Parsing select svc_pt_id, meas_type_id, read_time, value FROM
>> cts_svc_pt_latest_int_read where svc_pt_id = -9941235 and meas_type_id =
>> 146; [SharedPool-Worker-1] | 2016-09-30 18:15:00.446000 | 192.168.199.75 |
>> 111
>>
>> Preparing statement
>> [SharedPool-Worker-1] | 2016-09-30 18:15:00.446000 | 192.168.199.75 |
>> 209
>>
>> reading data from /192.168.170.186
>> [SharedPool-Worker-1] | 2016-09-30 18:15:00.446001 | 192.168.199.75 |
>> 370
>>
>> Sending READ message to /192.168.170.186 [MessagingService-Outgoing-/
>> 192.168.170.186] | 2016-09-30 18:15:00.446001 | 192.168.199.75 |
>> 450
>>
>> REQUEST_RESPONSE message received from /192.168.170.186
>> [MessagingService-Incoming-/192.168.170.186] | 2016-09-30
>> 18:15:00.448000 | 192.168.199.75 | 2469
>>
>> Processing response from /192.168.170.186
>> [SharedPool-Worker-8] | 2016-09-30 18:15:00.448000 | 192.168.199.75 |
>> 2609
>>
>> READ message received from /192.168.199.75 [MessagingService-Incoming-/
>> 192.168.199.75] | 2016-09-30 18:15:00.449000 | 192.168.170.186 |
>> 75
>>
>> Row cache miss
>> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449000 | 192.168.170.186 |
>> 218
>> Fetching data but not
>> populating cache as query does not query from the start of the partition
>> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449000 | 192.168.170.186 |
>> 246
>>
>> Executing single-partition query on cts_svc_pt_latest_int_read
>> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449000 | 192.168.170.186 |
>> 259
>>
>> Acquiring sstable references
>> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 |
>> 281
>>
>> Merging memtable contents
>> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 |
>> 295
>>
>> Merging data from sstable 8
>> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 |
>> 326
>>
>> Key cache hit for sstable 8
>> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 |
>> 351
>>
>> Merging data from sstable 7
>> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 |
>> 439
>>
>> Key cache hit for sstable 7
>> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 |
>> 468
>>
>> Read 1 live and 0 tombstone cells
>> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 |
>> 615
>>
>> Enqueuing response to /192.168.199.75
>> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449002 | 192.168.170.186 |
>> 766
>>
>> Sending REQUEST_RESPONSE message to /192.168.199.75
>> [MessagingService-Outgoing-/192.168.199.75] | 2016-09-30 18:15:00.449002
>> | 192.168.170.186 | 897
>>
>>
>> Request complete | 2016-09-30 18:15:00.448888 | 192.168.199.75 |
>> 2888
>>
>> Can please anyone tell me what I am doing wrong?
>>
>> Thanks,
>> Abhinav
>>
>
Re: Row cache not working
Posted by Abhinav Solan <ab...@gmail.com>.
Hi, can anyone please help me with this
Thanks,
Abhinav
On Fri, Sep 30, 2016 at 6:20 PM Abhinav Solan <ab...@gmail.com>
wrote:
> Hi Everyone,
>
> My table looks like this -
> CREATE TABLE test.reads (
> svc_pt_id bigint,
> meas_type_id bigint,
> flags bigint,
> read_time timestamp,
> value double,
> PRIMARY KEY ((svc_pt_id, meas_type_id))
> ) WITH bloom_filter_fp_chance = 0.1
> AND caching = {'keys': 'ALL', 'rows_per_partition': '10'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
>
> Have set up the C* nodes with
> row_cache_size_in_mb: 1024
> row_cache_save_period: 14400
>
> and I am making this query
> select svc_pt_id, meas_type_id, read_time, value FROM
> cts_svc_pt_latest_int_read where svc_pt_id = -9941235 and meas_type_id =
> 146;
>
> with tracing on every time it says Row cache miss
>
> activity
>
> | timestamp | source | source_elapsed
>
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------+-----------------+----------------
>
>
> Execute CQL3 query | 2016-09-30 18:15:00.446000 | 192.168.199.75 |
> 0
> Parsing select svc_pt_id, meas_type_id, read_time, value FROM
> cts_svc_pt_latest_int_read where svc_pt_id = -9941235 and meas_type_id =
> 146; [SharedPool-Worker-1] | 2016-09-30 18:15:00.446000 | 192.168.199.75 |
> 111
>
> Preparing statement
> [SharedPool-Worker-1] | 2016-09-30 18:15:00.446000 | 192.168.199.75 |
> 209
>
> reading data from /192.168.170.186
> [SharedPool-Worker-1] | 2016-09-30 18:15:00.446001 | 192.168.199.75 |
> 370
>
> Sending READ message to /192.168.170.186 [MessagingService-Outgoing-/
> 192.168.170.186] | 2016-09-30 18:15:00.446001 | 192.168.199.75 |
> 450
>
> REQUEST_RESPONSE message received from /192.168.170.186
> [MessagingService-Incoming-/192.168.170.186] | 2016-09-30 18:15:00.448000
> | 192.168.199.75 | 2469
>
> Processing response from /192.168.170.186
> [SharedPool-Worker-8] | 2016-09-30 18:15:00.448000 | 192.168.199.75 |
> 2609
>
> READ message received from /192.168.199.75 [MessagingService-Incoming-/
> 192.168.199.75] | 2016-09-30 18:15:00.449000 | 192.168.170.186 |
> 75
>
> Row cache miss
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449000 | 192.168.170.186 |
> 218
> Fetching data but not
> populating cache as query does not query from the start of the partition
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449000 | 192.168.170.186 |
> 246
>
> Executing single-partition query on cts_svc_pt_latest_int_read
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449000 | 192.168.170.186 |
> 259
>
> Acquiring sstable references
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 |
> 281
>
> Merging memtable contents
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 |
> 295
>
> Merging data from sstable 8
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 |
> 326
>
> Key cache hit for sstable 8
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 |
> 351
>
> Merging data from sstable 7
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 |
> 439
>
> Key cache hit for sstable 7
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 |
> 468
>
> Read 1 live and 0 tombstone cells
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449001 | 192.168.170.186 |
> 615
>
> Enqueuing response to /192.168.199.75
> [SharedPool-Worker-2] | 2016-09-30 18:15:00.449002 | 192.168.170.186 |
> 766
> Sending
> REQUEST_RESPONSE message to /192.168.199.75 [MessagingService-Outgoing-/
> 192.168.199.75] | 2016-09-30 18:15:00.449002 | 192.168.170.186 |
> 897
>
>
> Request complete | 2016-09-30 18:15:00.448888 | 192.168.199.75 |
> 2888
>
> Can please anyone tell me what I am doing wrong?
>
> Thanks,
> Abhinav
>