Re: storing indexes on ssd

On Tue, Feb 13, 2018 at 1:30 AM, Dan Kinder wrote: > Created https://issues.apache.org/jira/browse/CASSANDRA-14229 > This is confusing. You've already started the conversation here... How big are your index files in the end? Even if Cassandra doesn't cache them in or (off-) heap, they might a

RE: LWT broken?

Yes, non-applied LWT will return the row of the winning result. I agree, in theory I’d expect your code to have a correct behavior. You could also check release notes of later Cassandra versions for LWT related bugs. If your ids are timeUUID you could try to extract the time when the inconsiste

Re: Old tombstones not being cleaned up

Hi Eric, I had not seen your talk, it was very informative thank you! :) Based on your talk, I can see how tombstones might noget get removed during normal operations under certain conditions. But I am not sure our scenario fit those conditions. We have less than 100.000 live rows in the table i

Cassandra is not running

Hello everyone: Whenever I try to run the Cassandra it stop with status: result of [sudo service cassandra status] command: ● cassandra.service - LSB: distributed storage system for structured data Loaded: loaded (/etc/init.d/cassandra; bad; vendor preset: enabled) Active: active (exited)

Re: if the heap size exceeds 32GB..

In most cases, Cassandra is pretty efficient about memory usage. However, if your use case does require/need/demand more memory for your workload, I would not hesitate to use heap > 32 GB. FYI, we have configured our heap for 84 GB. However there's more tuning that we have done beyond just the hea

Re: node restart causes application latency

Then could it be that calling `nodetool drain` after calling `nodetool disablegossip` is what causes the problem? On Mon, Feb 12, 2018 at 6:12 PM, kurt greaves wrote: > > ​Actually, it's not really clear to me why disablebinary and thrift are > necessary prior to drain, because they happen in th

Re: Cassandra is not running

Hi, Such a quick failure might indicate that you are trying to start Cassandra with the latest JDK which is not yet supported. You should have a look at the /var/log/system.log On 13 February 2018 at 16:03, Irtiza Ali wrote: > Hello everyone: > > Whenever I try to run the Cassandra it stop wit

Re: Cassandra is not running

Thank you i will check it On 13 Feb 2018 20:16, "Nicolas Guyomar" wrote: > Hi, > > Such a quick failure might indicate that you are trying to start Cassandra > with the latest JDK which is not yet supported. > > You should have a look at the /var/log/system.log > > On 13 February 2018 at 16:03,

Re: Cassandra is not running

What should I do now? On 13 Feb 2018 20:21, "Irtiza Ali" wrote: > Thank you i will check it > > > On 13 Feb 2018 20:16, "Nicolas Guyomar" wrote: > >> Hi, >> >> Such a quick failure might indicate that you are trying to start >> Cassandra with the latest JDK which is not yet supported. >> >> You

Re: Cassandra is not running

What error message or WARN you got in system.log file and also check output.log file .. On Feb 13, 2018 11:34 PM, "Irtiza Ali" wrote: > What should I do now? > > On 13 Feb 2018 20:21, "Irtiza Ali" wrote: > >> Thank you i will check it >> >> >> On 13 Feb 2018 20:16, "Nicolas Guyomar" >> wrote:

Re: Cassandra is not running

output of the cassandra system log file: INFO [main] 2018-02-13 20:25:40,973 DatabaseDescriptor.java:367 - DiskAccessMode 'auto' determined to be mmap, indexAccessMode is mmap INFO [main] 2018-02-13 20:25:40,973 DatabaseDescriptor.java:421 - Global memtable on-heap threshold is enabled at 480MB

Re: Cassandra is not running

1.8.0_161 is not yet supported - try 1.8.0_151 > Am 13.02.2018 um 16:44 schrieb Irtiza Ali : > > 1.8.0_161

Re: Cassandra is not running

Thank you On 13 Feb 2018 20:45, "Jürgen Albersdorfer" wrote: > 1.8.0_161 is not yet supported - try 1.8.0_151 > > Am 13.02.2018 um 16:44 schrieb Irtiza Ali : > > 1.8.0_161 > > >

Re: Cassandra is not running

Downgrade your Java version please On Feb 13, 2018 11:46 PM, "Irtiza Ali" wrote: > Thank you > > On 13 Feb 2018 20:45, "Jürgen Albersdorfer" > wrote: > >> 1.8.0_161 is not yet supported - try 1.8.0_151 >> >> Am 13.02.2018 um 16:44 schrieb Irtiza Ali : >> >> 1.8.0_161 >> >> >>

RE: Cassandra is not running

Adding known issue reference and fix versions: CASSANDRA-14173 Fix Version/s: 3.11.2/4.0 From: Jürgen Albersdorfer [mailto:jalbersdor...@gmail.com] Sent: Tuesday, February 13, 2018 9:45 AM To: user@cassandra.apache.org Subject: Re: Cassandra i

Re: Cassandra is not running

On 02/13/2018 09:45 AM, Jürgen Albersdorfer wrote: > 1.8.0_161 is not yet supported - try 1.8.0_151 > >> Am 13.02.2018 um 16:44 schrieb Irtiza Ali > >: >> >> 1.8.0_161 > Or install the 3.11.2 tentative release, which should work fine on 1.8.0_161. https://lists.apache.org/t

Re: Cassandra is not running

Thankyou everyone On 13 Feb 2018 8:50 p.m., "Michael Shuler" wrote: > On 02/13/2018 09:45 AM, Jürgen Albersdorfer wrote: > > 1.8.0_161 is not yet supported - try 1.8.0_151 > > > >> Am 13.02.2018 um 16:44 schrieb Irtiza Ali >> >: > >> > >> 1.8.0_161 > > > > Or install the 3.

Re: if the heap size exceeds 32GB..

Wow, an 84GB heap! Would you mind disclosing the kind of data requirements behind this choice? And what kind of STW GC pauses do you see? On Tue, Feb 13, 2018 at 10:06 AM, Thakrar, Jayesh < jthak...@conversantmedia.com> wrote: > In most cases, Cassandra is pretty efficient about memory usage.

Re: if the heap size exceeds 32GB..

I'm not Jayesh, but I assume they're using G1GC (or one of the proprietary collectors) that does a lot more concurrent marking without STW. If you ran 84G heaps with CMS, you'd either need to dramatically tune your CMS initiating occupancy, or you'd probably see horrible, horrible pauses. On

Re: if the heap size exceeds 32GB..

Sure, here are our settings: # # Simpler, new generation G1GC settings. # JVM_OPTS="$JVM_OPTS -XX:+UseG1GC" JVM_OPTS="$JVM_OPTS -XX:+UnlockExperimentalVMOptions" JVM_OPTS="$JVM_OPTS -XX:+ParallelRefProcEnabled" JVM_OPTS="$JVM_OPTS -XX:MaxGCPauseMillis=50" JVM_OPTS="$JVM_OPTS -XX:MaxTenurin

Re: storing indexes on ssd

On a single node that's a bit less than half full, the index files are 87G. How will OS disk cache know to keep the index file blocks cached but not cache blocks from the data files? As far as I know it is not smart enough to handle that gracefully. Re: ram expensiveness, see https://www.extremet

Re: storing indexes on ssd

It seems like cart-before-horse decision to assume you want to keep your index files cached but not your data files. Why not rely on lvmcache’s statistics about file access to determine what to keep and what not to? It’s going to keep your most heavily hit blocks in the cache and your least hi

Re: storing indexes on ssd

On Tue, Feb 13, 2018 at 10:46 PM, Dan Kinder wrote: > On a single node that's a bit less than half full, the index files are 87G. > That's not small, true. Out of curiosity: how much data per node do you have in total? How will OS disk cache know to keep the index file blocks cached but not >