RE: if the heap size exceeds 32GB..

Stick with 31G in your case. Another article on compressed Oops: https://blog.codecentric.de/en/2014/02/35gb-heap-less-32gb-java-jvm-memory-oddities/ Thomas From: Eunsu Kim [mailto:eunsu.bil...@gmail.com] Sent: Dienstag, 13. Februar 2018 08:09 To: user@cassandra.apache.org Subject: if the heap

Re: if the heap size exceeds 32GB..

Here is a useful guide on tuning Cassandra heap https://docs.datastax.com/en/cassandra/3.0/cassandra/operations/opsTuneJVM.html#opsTuneJVM__tuning-the-java-heap . TL;DR You wouldn't want to allocate more than 1/2 of physical memory to heap so you wouldn't exceed 32 GB anyway. On Mon, Feb 12,

if the heap size exceeds 32GB..

https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html#compressed_oops According to the article above, if the heap size of the JVM is about 32GB, it is a waste of memory because

Re: Old tombstones not being cleaned up

Hi Jeff, Thank you for your input :) Yes we have cassandra reaper running incremental repairs on our cluster, so that might very well be the case. But I did execute a "nodetool repair", "nodetool cleanup" before the compaction, should that not have fixed any left-overs from an incremental repair?

?????? does copy command will clear all the old data?

Thanks Nandan for the confirmation.I also did the test. -- -- ??: "@Nandan@"; : 2018??2??13??(??) 12:52 ??: "user"; : Re: does copy command will clear all the old

Re: does copy command will clear all the old data?

Hi Peng, Copy command will append upsert all data [based on size] to your existing Cassandra table. Just for testing, I executed before for 50 data by using COPY command into small cql table and it work very fine. Point to make sure :- Please check your primary key before play with COPY

does copy command will clear all the old data?

Dear All, I'm trying to import csv file to a table with copy command?The question is: will the copy command clear all the old data in this table?as we only want to append the csv file to this table Thanks

Re: Roadmap for 4.0

Advantages of cutting a release sooner than later: 1) The project needs to constantly progress forward. Releases are the most visible part of that. 2) Having a huge changelog in a release increases the likelihood of bugs that take time to find. Advantages of a slower release: 1) We don't do major

Re: storing indexes on ssd

Created https://issues.apache.org/jira/browse/CASSANDRA-14229 On Mon, Feb 12, 2018 at 12:10 AM, Mateusz Korniak < mateusz-li...@ant.gliwice.pl> wrote: > On Saturday 10 of February 2018 23:09:40 Dan Kinder wrote: > > We're optimizing Cassandra right now for fairly random reads on a large > >

Re: node restart causes application latency

​Actually, it's not really clear to me why disablebinary and thrift are necessary prior to drain, because they happen in the same order during drain anyway. It also really doesn't make sense that disabling gossip after drain would make a difference here, because it should be already stopped. This

Re: node restart causes application latency

Drain will take care of stopping gossip, and does a few tasks before stopping gossip (stops batchlog, hints, auth, cache saver and a few other things). I'm not sure why this causes a side effect when you restart the node, but there should be no need to issue a disablegossip anyway, just leave that

Releases 2.1.20, 2.2.12, 3.0.16, & 3.11.2 are now up for vote by the PMC

Tentative tags have been pushed and releases 2.1.20, 2.2.12, 3.0.16, & 3.11.2 are now up for vote by the PMC to address CASSANDRA-14092, as well as all the other fixes/features committed to the respective branches. If you would like the links to the tentative release artifacts/packages and

Re: LWT broken?

On 2/12/18 2:04 AM, Jacques-Henri Berthemet wrote: Mahdi, you don’t need to re-read at CL ONE on line 9. When a LWT statement is not applied, the values that prevented the LWT are returned as part of the response, I’d expect them to be more consistent than your read. I’m not 100% sure it’s

Re: node restart causes application latency

Interestingly, it seems that changing the order of steps I take during the node restart resolves the problem. Instead of: `nodetool disablebinary && nodetool disablethrift && *nodetool disablegossip* && nodetool drain && sudo service cassandra restart`, if I do: `nodetool disablebinary &&

Re: Setting min_index_interval to 1?

@Hannu this was based on the assumption that if we receive a read for a key that is sampled, it'll be treated as cached and won't go to the index on disk. Part of my question was whether that's the case, I'm not sure. Btw I ended up giving up on this, trying the key cache route already showed

Re: Old tombstones not being cleaned up

Hi, Just in case you haven't seen it, I gave a talk last year at the summit. In the first part of the talk I speak for a while about the lifecycle of a tombstone, and how they don't always get cleaned up when you might expect. https://youtu.be/BhGkSnBZgJA It looks like you're deleting cluster

Re: node restart causes application latency

Any other ideas? If I simply stop the node, there is no latency problem, but once I start the node the problem appears. This happens consistently for all nodes in the cluster On Wed, Feb 7, 2018 at 11:36 AM, Mike Torra wrote: > No, I am not > > On Wed, Feb 7, 2018 at

Re: Old tombstones not being cleaned up

When you force compacted, did you end up with 1 sstable or 2? If 2, did you ever run (incremental) repair on some of the data? If so, it moves the repaired sstable to a different compaction manager, which means it won’t purge the tombstone if it shadows data in the unrepaired set -- Jeff

Re: GDPR, Right to Be Forgotten, and Cassandra

Hi, Thank you Jon for this DeletingCS I'll have a look. Not being able to query/access a user data, or at least not being able to identify a client from its data (@Stefan *crypto shredding and pseudonymization strategies)* makes sense now I did interpret the legal text a bit too far on the

RE: LWT broken?

Mahdi, you don’t need to re-read at CL ONE on line 9. When a LWT statement is not applied, the values that prevented the LWT are returned as part of the response, I’d expect them to be more consistent than your read. I’m not 100% sure it’s the case for 2.0.x but it’s the case for Cassandra 2.2.

Re: storing indexes on ssd

On Saturday 10 of February 2018 23:09:40 Dan Kinder wrote: > We're optimizing Cassandra right now for fairly random reads on a large > dataset. In this dataset, the values are much larger than the keys. I was > wondering, is it possible to have Cassandra write the *index* files > (*-Index.db) to