It’s pretty clear to me that the only thing that gets put into the caches are
the top N rows.
https://github.com/apache/cassandra/blob/0db88242c66d3a7193a9ad836f9a515b3ac7f9fa/src/java/org/apache/cassandra/db/SinglePartitionReadCommand.java#L523
It may fetch more, but it doesn’t cache it. It may
> On 12 Mar 2018, at 14:45, Rahul Singh wrote:
>
> I may be wrong, but what I’ve read and used in the past assumes that the
> “first” N rows are cached and the clustering key design is how I change what
> N rows are put into memory. Looking at the code, it seems that’s the case.
So we agree
I may be wrong, but what I’ve read and used in the past assumes that the
“first” N rows are cached and the clustering key design is how I change what N
rows are put into memory. Looking at the code, it seems that’s the case.
The language of the comment basically says that it holds in cache what
Hi,
My goal is to make sure that I understand functionality correctly and that the
documentation is accurate.
The question in other words: Is the documentation or the comment in the code
wrong (or inaccurate).
Hannu
> On 12 Mar 2018, at 13:00, Rahul Singh wrote:
>
> What’s the goal? How bi
What’s the goal? How big are your partitions , size in MB and in rows?
--
Rahul Singh
rahul.si...@anant.us
Anant Corporation
On Mar 12, 2018, 6:37 AM -0400, Hannu Kröger , wrote:
> Anyone?
>
> > On 4 Mar 2018, at 20:45, Hannu Kröger wrote:
> >
> > Hello,
> >
> > I am trying to verify and unders
Anyone?
> On 4 Mar 2018, at 20:45, Hannu Kröger wrote:
>
> Hello,
>
> I am trying to verify and understand fully the functionality of row cache in
> Cassandra.
>
> I have been using mainly two different sources for information:
> https://github.com/apache/cassandra/blob/0db88242c66d3a7193a9ad
Thanks All.
-- --
??: "Steinmaurer, Thomas";;
: 2017??9??20??(??) 1:38
??: "user@cassandra.apache.org";
: RE: Row Cache hit issue
Hi,
additionally, with saved (key) caches, we had some sort of
:06
To: cassandra
Subject: Re: Row Cache hit issue
Hi Peng,
C* periodically saves cache to disk, to solve cold start problem. If
row_cache_save_period=0, it means C* does not save cache to disk. But the cache
is still working, if it's enabled in table schema, just the cache will be empty
Hi Peng,
C* periodically saves cache to disk, to solve cold start problem. If
row_cache_save_period=0, it means C* does not save cache to disk. But the
cache is still working, if it's enabled in table schema, just the cache
will be empty after restart.
--Dikang.
On Tue, Sep 19, 2017 at 8:27 PM,
And we are using C* 2.1.18.
-- Original --
From: "";<2535...@qq.com>;
Date: Wed, Sep 20, 2017 11:27 AM
To: "user";
Subject: Row Cache hit issue
Dear All,
The default row_cache_save_period=0,looks Row Cache does not work in this
situation?
b
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:3
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
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 glo
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 heav
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
h row cache
enabled.
From: Abhinav Solan
Reply-To: "user@cassandra.apache.org"
Date: Monday, October 3, 2016 at 1:38 PM
To: "user@cassandra.apache.org"
Subject: Re: Row cache not working
It's cassandra 3.0.7,
I had to set caching = {'keys': 'ALL',
y very
>> very dangerous if you have very wide rows in any of your tables with row
>> cache enabled.
>>
>>
>>
>>
>>
>>
>>
>> From: Abhinav Solan
>> Reply-To: "user@cassandra.apache.org"
>> Date: Monday, O
us if you have very wide rows in any of your tables with row
> cache enabled.
>
>
>
>
>
>
>
> *From: *Abhinav Solan
> *Reply-To: *"user@cassandra.apache.org"
> *Date: *Monday, October 3, 2016 at 1:38 PM
> *To: *"user@cassandra.apache.org"
&
very very
dangerous if you have very wide rows in any of your tables with row cache
enabled.
From: Abhinav Solan
Reply-To: "user@cassandra.apache.org"
Date: Monday, October 3, 2016 at 1:38 PM
To: "user@cassandra.apache.org"
Subject: Re: Row cache not working
version would be useful)?
>
>
>
> *From: *Abhinav Solan
> *Reply-To: *"user@cassandra.apache.org"
> *Date: *Monday, October 3, 2016 at 11:35 AM
> *To: *"user@cassandra.apache.org"
> *Subject: *Re: Row cache not working
>
>
>
> Hi, can anyone
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
Reply-To: "user@cassandra.apache.org"
Date: Monday, October 3, 2016 at 11:35 AM
To: "user@cassandra.apache.org"
Subject: Re: Row cach
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
Hi, can anyone please help me with this
Thanks,
Abhinav
On Fri, Sep 30, 2016 at 6:20 PM Abhinav Solan
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 do
The row cache saves partition data off-heap, which means that every cache
hit require copying/deserializing the cached partition into the heap, and
the more rows per partition you cache, the long it will take. Which is why
it's currently not a good cache too much rows per partition (unless you
know
On Mon, Mar 31, 2014 at 11:37 AM, Wayne Schroeder <
wschroe...@pinsightmedia.com> wrote:
> I found a lot of documentation about the read path for key and row caches,
> but I haven't found anything in regard to the write path. My app has the
> need to record a large quantity of very short lived te
On Mar 31, 2014 12:38 PM, "Wayne Schroeder"
wrote:
> I found a lot of documentation about the read path for key and row caches,
> but I haven't found anything in regard to the write path. My app has the
> need to record a large quantity of very short lived temporal data that will
> expire within
Perhaps I should clarify my question. Is this possible / how might I
accomplish this with cassandra?
Wayne
On Mar 31, 2014, at 12:58 PM, Robert Coli
mailto:rc...@eventbrite.com>>
wrote:
On Mon, Mar 31, 2014 at 9:37 AM, Wayne Schroeder
mailto:wschroe...@pinsightmedia.com>> wrote:
I found a
On Mon, Mar 31, 2014 at 9:37 AM, Wayne Schroeder <
wschroe...@pinsightmedia.com> wrote:
> I found a lot of documentation about the read path for key and row caches,
> but I haven't found anything in regard to the write path. My app has the
> need to record a large quantity of very short lived tem
Thank you everyone for your input.
My dataset is ~100G of size with 1 or 2 read intensive column families. The
cluster has plenty of RAM. I'll start off small with 4G of row cache and
monitor the success rate.
Katriel
On Thu, Jan 23, 2014 at 9:17 PM, Robert Coli wrote:
> On Wed, Jan 22, 2014 a
On Wed, Jan 22, 2014 at 11:13 PM, Katriel Traum wrote:
> I was if anyone has any pointers or some advise regarding using row cache
> vs leaving it up to the OS buffer cache.
>
> I run cassandra 1.1 and 1.2 with JNA, so off-heap row cache is an option.
>
Many people have had bad experiences with
My experience has been that the row cache is much more effective.
However, reasonable row cache sizes are so small relative to RAM that I
don't see it as a significant trade-off unless it's in a very memory
constrained environment. If you want to enable the row cache (a big if)
you probably wa
Our experience is that you want to have all your very hot data fit in the row
cache (assuming you don’t have very large rows), and leave the rest for the OS.
Unfortunately, it completely depends on your access patterns and data what is
the right size for the cache - zero makes sense for a lot
s.burrou...@gmail.com
> >> To: user@cassandra.apache.org
> >> CC: fsareshw...@quantcast.com
> >> Subject: Re: row cache
> >>
> >> On 09/01/2013 03:06 PM, Faraaz Sareshwala wrote:
> >> > Yes, that is correct.
> >> >
> >> > The Se
ion.
>
> -SC
>
>
>> Date: Tue, 3 Sep 2013 12:01:59 -0400
>> From: chris.burrou...@gmail.com
>> To: user@cassandra.apache.org
>> CC: fsareshw...@quantcast.com
>> Subject: Re: row cache
>>
>> On 09/01/2013 03:06 PM, Faraaz Sareshwala wrote:
>>
Thank you all for your valuable comments and information.
-SC
> Date: Tue, 3 Sep 2013 12:01:59 -0400
> From: chris.burrou...@gmail.com
> To: user@cassandra.apache.org
> CC: fsareshw...@quantcast.com
> Subject: Re: row cache
>
> On 09/01/2013 03:06 PM, Faraaz Sareshwala wr
On 09/01/2013 03:06 PM, Faraaz Sareshwala wrote:
Yes, that is correct.
The SerializingCacheProvider stores row cache contents off heap. I believe you
need JNA enabled for this though. Someone please correct me if I am wrong here.
The ConcurrentLinkedHashCacheProvider stores row cache contents o
on disk). It could
> live on heap or native memory depending on the cache provider? Is that right?
>
> -SC
>
>
> > Date: Fri, 23 Aug 2013 18:58:07 +0100
> > From: b...@dehora.net
> > To: user@cassandra.apache.org
> > Subject: Re: row cache
> >
>
It is my understanding that row cache is on the memory (Not on disk). It could
live on heap or native memory depending on the cache provider? Is that right?
-SC
> Date: Fri, 23 Aug 2013 18:58:07 +0100
> From: b...@dehora.net
> To: user@cassandra.apache.org
> Subject: Re: row
I can't emphasise enough testing row caching against your workload for
sustained periods and comparing results to just leveraging the
filesystem cache and/or ssds. That said. The default off-heap cache can
work for structures that don't mutate frequently, and whose rows are not
very wide such t
On Thu, Aug 22, 2013 at 7:53 PM, Faraaz Sareshwala <
fsareshw...@quantcast.com> wrote:
> According to the datastax documentation [1], there are two types of row
> cache providers:
>
...
> The off-heap row cache provider does indeed invalidate rows. We're going
> to look into using the ConcurrentL
After a bit of searching, I think I've found the answer I've been looking for.
I guess I didn't search hard enough before sending out this email. Thank you
all for the responses.
According to the datastax documentation [1], there are two types of row cache
providers:
row_cache_provider
(Defaul
If you are using off-heap memory for row cache, "all writes invalidate the
entire row" should be correct.
Boris
On Fri, Aug 23, 2013 at 8:32 AM, Robert Coli wrote:
> On Wed, Aug 14, 2013 at 10:56 PM, Faraaz Sareshwala <
> fsareshw...@quantcast.com> wrote:
>
>>
>>- All writes invalidate the
On Wed, Aug 14, 2013 at 10:56 PM, Faraaz Sareshwala <
fsareshw...@quantcast.com> wrote:
>
>- All writes invalidate the entire row (updates thrown out the cached
>row)
>
> This is not correct. Writes are added to the row, if it is in the row
cache. If it's not in the row cache, the row is n
> Should I raise a ticket since we are at least 3 having this issue from what I
> saw in the mailing list ?
Sure, if you can come up with steps to reproduce the problem.
Cheers
-
Aaron Morton
Freelance Cassandra Consultant
New Zealand
@aaronmorton
http://www.thelastpickle.com
Thanks, I'll let you know when I'll do so. But any Idea about the increase
of the heap used if all seems to be well configured ? Should I raise a
ticket since we are at least 3 having this issue from what I saw in the
mailing list ?
2013/3/14 aaron morton
> > No, I didn't. I used the nodetool s
> No, I didn't. I used the nodetool setcachecapacity and didn't restart the
> node.
ok.
> I find them hudge, and just happened on the node in which I had enabled row
> cache. I just enabled it on .164 node from 10:45 to 10:48 and the heap size
> doubled from 3.5GB to 7GB (out of 8, which induc
I am using C*1.1.6.
"Did you restart the node after changing the row_cache_size_in_mb ?"
No, I didn't. I used the nodetool setcachecapacity and didn't restart the
node.
"The changes in GC activity are not huge and may not be due to cache
activity"
I find them hudge, and just happened on the nod
What version are you using?
Sounds like you have configured it correctly. Did you restart the node after
changing the row_cache_size_in_mb ?
The changes in GC activity are not huge and may not be due to cache activity.
Have they continued after you enabled the row cache?
What is the output from
I have the same problem!
2013/3/11 Alain RODRIGUEZ
> I can add that I have JNA corectly loaded, from the logs: "JNA mlockall
> successful"
>
>
> 2013/3/11 Alain RODRIGUEZ
>
>> Any clue on this ?
>>
>> Row cache well configured could avoid us a lot of disk read, and IO
>> is definitely our bottl
I can add that I have JNA corectly loaded, from the logs: "JNA mlockall
successful"
2013/3/11 Alain RODRIGUEZ
> Any clue on this ?
>
> Row cache well configured could avoid us a lot of disk read, and IO
> is definitely our bottleneck... If someone could explain why the row cache
> has so much i
Any clue on this ?
Row cache well configured could avoid us a lot of disk read, and IO
is definitely our bottleneck... If someone could explain why the row cache
has so much impact on my JVM and how to avoid it, it would be appreciated
:).
2013/3/8 Alain RODRIGUEZ
> Hi,
>
> We have some issue
The first thing I look for with timeouts like that is a flush storm causing
blocking in the write path (due to the internal "switch lock").
Take a look in the logs, for a number of messages such as "enqueuing CF…" and
"writing cf..". Look for a pattern of enqueuing cf messages that occur
immed
Does anyone see anything wrong in these settings? Anything to account for a 8s
timeout during a counter increment?
Thanks,
André
On 31/12/2012, at 14:35, André Cruz wrote:
> On Dec 29, 2012, at 8:53 PM, Mohit Anchlia wrote:
>
>> Can you post gc settings? Also check logs and see what it says
On Dec 29, 2012, at 8:53 PM, Mohit Anchlia wrote:
> Can you post gc settings? Also check logs and see what it says
These are the relevant jam settings:
-home /usr/lib/jvm/j2re1.6-oracle/bin/../
-ea -javaagent:/usr/share/cassandra/lib/jamm-0.2.5.jar
-XX:+UseThreadPriorities
-XX:ThreadPriorityP
Can you post gc settings? Also check logs and see what it says
Also post how many writes and reads along with avg row size
Sent from my iPhone
On Dec 29, 2012, at 12:28 PM, rohit bhatia wrote:
> i assume u mean 8 seconds and not 8ms..
> thats pretty huge to be caused by gc. Is there lot of lo
i assume u mean 8 seconds and not 8ms..
thats pretty huge to be caused by gc. Is there lot of load on your servers?
You might also need to check for memory contention
Regarding GC, since its parnew all u can really do is increase heap and
young gen size, or modify tenuring rate. But that can't be
On 29/12/2012, at 16:59, rohit bhatia wrote:
> Reads during a write still occur during a counter increment with CL ONE, but
> that latency is not counted in the request latency for the write. Your local
> node write latency of 45 microseconds is pretty quick. what is your timeout
> and the wri
Reads during a write still occur during a counter increment with CL ONE,
but that latency is not counted in the request latency for the write. Your
local node write latency of 45 microseconds is pretty quick. what is your
timeout and the write request latency you see. In our deployment we had
some
> INFO [OptionalTasks:1] 2012-11-19 13:08:58,868 ColumnFamilyStore.java (line
> 451) completed loading (5175655 ms; 13259976 keys) row cache
So it was reading 2,562 rows per second during startup. I'd say that's not
unreasonable performance for 13 million rows. It will get faster in 1.2, but
for
On Mon, Nov 19, 2012 at 6:17 AM, Andras Szerdahelyi <
andras.szerdahe...@ignitionone.com> wrote:
> How is the "saved row cache file" processed? Are the cached row keys
> simply iterated over and their respective rows read from SSTables -
> possibly creating random reads with small enough sstable f
Wei,
i'm using the off-heap ( serialised ) row cache and front the entire thing with
memcached in the middle layer ( to prevent the most actively requested rows
from pressuring the Cassandra heap ). If you ask how much the pointers to the
off-heap memory will take.. time will tell ( it should b
Aaron,
What version are you on ?
1.1.5
Do you know how many rows were loaded ?
INFO [OptionalTasks:1] 2012-11-19 13:08:58,868 ColumnFamilyStore.java (line
451) completed loading (5175655 ms; 13259976 keys) row cache
In both cases I do not believe the cache is stored in token (or key) order.
hanks.
-Wei
From: aaron morton
To: user@cassandra.apache.org
Sent: Monday, November 19, 2012 1:00 PM
Subject: Re: row cache re-fill very slow
i was just wondering if anyone else is experiencing very slow ( ~ 3.5 MB/sec )
re-fill of the row cache at start u
> i was just wondering if anyone else is experiencing very slow ( ~ 3.5 MB/sec
> ) re-fill of the row cache at start up.
It was mentioned the other day.
What version are you on ?
Do you know how many rows were loaded ? When complete it will log a message
with the pattern
"completed loading
No cache can only have data from the local node since write operations
need to be able to evict items.
On Thu, May 17, 2012 at 4:42 PM, Maxim Potekhin wrote:
> Hello,
>
> when I chose to have a rowcache -- will it contain data that is owned by
> other nodes?
>
> Thanks
>
> Maxim
>
this is how I tested it:
1) load cache with 1.500.000 entries
2) execute fill gc
3) mesure heap size (using visual vm)
4) execute flush row cahce over cli
5) execute full gc
6) and again mesure hap usage
The difference between 6) and 3) is the heap size used by cache
On Fri, Oct 28, 2011 at 3:26
> Is it possible, that single row (8 columns) can allocate about 2KB heap?
It sounds a bit much, though not extremely so (depending on how much
overhead there is per-column relative to per-row). Are you definitely
looking at the live size of the heap (for example, trigger a full GC
and look at res
Hi,
The JConsole shows that the capacity > 0.
10x
--
View this message in context:
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Row-cache-tp6532887p6549420.html
Sent from the cassandra-u...@incubator.apache.org mailing list archive at
Nabble.com.
Just to make sure:
The yaml doesn't matter. The cache config is stored in the system tables. Its
the "CREATE ... WITH ..." stuff you did via cassandra-cli to create the CF.
In Jconsole you see that the cache capacity is > 0?
On Jul 4, 2011, at 11:18 AM, Shay Assulin wrote:
> Hi,
>
> The row c
Hi,
The row cache capacity > 0.
after reading a row - the Caches..KeyCache.Requests attribute
gets incremented but the ColumnFamilies...ReadCount attribute
remains zero and the Caches..RowCache.Size and Requsts
attributes remain zero as well.
It looks like the row-cache is disabled although the
Here's my understanding of things ... (this applies only for the regular heap
implementation of row cache)
> Why Cassandra does not cache a row that was requested few times?
What does the cache capacity read. Is it > 0?
> What the ReadCount attribute in ColumnFamilies indicates and why it rema
While I think "adaptively cache just hot parts of the row wherever
they are" is not feasible, the limitations you describe should be
fine. I think it's a clever idea, and probably widely useful.
On Mon, Jan 3, 2011 at 10:48 AM, Daniel Doubleday
wrote:
> Hi,
>
> we have a couple of use cases with
On Fri, Nov 5, 2010 at 2:41 PM, Jeremy Davis
wrote:
> What do you mean by "Turning Over quickly"? What is Turning over? If it
> needs to create an entirely new row, then that would create GC pressure for
> sure... But if you are just updating a column in a row that is already in
> the cache, then
> In short, it seems like the general advice is unless you have a set of nearly
> static rows, AND they all fit in the cache, then rowcache is not recommended.
That's been our experience. Leave the memory for the OS cache instead.
Dave
On Friday, November 5, 2010, Jeremy Davis wrote:
> What do
What do you mean by "Turning Over quickly"? What is Turning over? If it
needs to create an entirely new row, then that would create GC pressure for
sure... But if you are just updating a column in a row that is already in
the cache, then I would think that would be the optimal situation.
OTOH, you
On Fri, Nov 5, 2010 at 1:41 PM, Jeremy Davis
wrote:
> I saw in the Riptano "Tuning Cassandra" slide deck that the row cache can
> be detrimental if there are a lot of updates to the cached row. Is this
> because the cache is not write through, and every update necessitates
> creation of a new row?
On Sun, Aug 8, 2010 at 5:24 AM, aaron morton wrote:
> Not sure how feasible it is or if it's planned. But it would probably
> require that the nodes are able so share the state of their row cache so as
> to know which parts to warm. Otherwise it sounds like you're assuming the
> node can hold the
Not sure how feasible it is or if it's planned. But it would probably require
that the nodes are able so share the state of their row cache so as to know
which parts to warm. Otherwise it sounds like you're assuming the node can hold
the entire data set in memory.
If you know in your applicati
78 matches
Mail list logo
