detail of compactionstats, pending tasks

Hello Folks, Is it possible to findout detail of those 275 pending tasks compactionstats command output is showing? I’ve bumpedup concurrent_compactors to 25 though not all threads are compacting, only 8 threads are being used so i’m wondering how can I utilize all configured concurrent

Re: Understanding Messages in the Debug.log

> > > The message in the debug log is > > DEBUG [GossipStage:1] 2017-09-21 09:19:52,627 FailureDetector.java:456 - > Ignoring interval time of 2000275419 > > > Did you truncate the log message? There should be and "for [endpoint]" on the end which should help you narrow things down to a set of

RE: Massive deletes -> major compaction?

So, let me make sure my assumptions are correct (and let others learn as well): - A major compaction would read all sstables at once (ignoring the max_threshold), thus the potential for needing double the disk space (of course if it wrote 30% less, it wouldn’t be double…) -

Re: detail of compactionstats, pending tasks

Pending tasks are not a queue, they are an estimation of the amount of work it would take to reach a perfect compaction point, but the compactions aren’t independent from one another. For instance, with LCS you may have a compaction from L0 -> L1, which triggers a L1 -> L2 compaction. You

Re: Understanding Messages in the Debug.log

Could also be a network hiccup, an NTP problem, a disk pause, or anything that causes a long gc pause including misconfigured heap. Are they all on the same machine? Or all instances in the cluster? If there are so many you need to root cause it, you probably want to look for correlation with

RE: Understanding Messages in the Debug.log

Thanks Jacob, I’ve already seen this, but it doesn’t answer my question, as this is a production Cluster, which at present, has no data and is not being written too, its being built to go live shortly, so with no data, a Keyspace with a table designed but no data in it, only system databases,

Re: Understanding Messages in the Debug.log

The message is caused by the Gossip message exchanged. It doesn't have anything to do with the load on the cluster. I asked the same question on the datastax slack. This is the answer from one of the Datastax engineers (Erick Ramirez): "`FailureDetector` checks if a node hasn't responded for 5

fromJson(null) throws java.lang.NullPointerException on Cassandra 3.11

Hi All Basically, fromJson throws a java.lang.NullPointerException when NULL is passed, instead of just returning a NULL itself. Say I create a UDT and a table as follows: create type type1 ( id int, name text ); create table table1 ( id int, t FROZEN,

Re: fromJson(null) throws java.lang.NullPointerException on Cassandra 3.11

It’s a bug. Should file a JIRA if one doesn’t already exist. -- Jeff Jirsa > On Sep 21, 2017, at 8:16 AM, Marcel Villet wrote: > > Hi All > > Basically, fromJson throws a java.lang.NullPointerException when NULL is > passed, instead of just returning a NULL itself. Say I

RE: COMMERCIAL: Re: fromJson(null) throws java.lang.NullPointerException on Cassandra 3.11

Cool thanks, will do. -Original Message- From: Jeff Jirsa [mailto:jji...@gmail.com] Sent: Thursday, September 21, 2017 5:58 PM To: user@cassandra.apache.org Subject: COMMERCIAL: Re: fromJson(null) throws java.lang.NullPointerException on Cassandra 3.11 It’s a bug. Should file a JIRA if

Re: Drastic increase in disk usage after starting repair on 3.7

So I got to the bottom of this -- turns out it's not an issue with Cassandra at all. Seems that whenever these instances were set up we had originally mounted 2TB drives from /dev/xvdc and those were persisted to /etc/fstab, but at some point someone unmounted those and replaced them with 4TB

Re: Understanding Messages in the Debug.log

check out this thread - https://www.mail-archive.com/user@cassandra.apache.org/msg52313.html -- Jacob Shadix On Thu, Sep 21, 2017 at 4:56 AM, Jonathan Baynes < jonathan.bay...@tradeweb.com> wrote: > Good Morning Community, > > > > Can anyone help me understand what these messages (and I have a

RE: Understanding Messages in the Debug.log

Thanks Jeff, They are on all instances of the cluster, with the same timeframe (give or take). Ill look into your suggestions., thank you for your guidance. From: Jeff Jirsa [mailto:jji...@gmail.com] Sent: 21 September 2017 12:48 To: user@cassandra.apache.org Subject: Re: Understanding

Re: Drastic increase in disk usage after starting repair on 3.7

Thanks for the suggestions guys. Nicolas, I just checked nodetool listsnapshots and it doesn't seem like those are causing the increase: Snapshot Details: Snapshot nameKeyspace name Column family name True size Size on disk

Pending-range-calculator during bootstrapping

Dear All, when we are bootstrapping a new node,we are experiencing high cpu load and this affect the rt ,and we noticed that it's mainly costing on Pending-range-calculator ,this did not happen before. We are using C* 2.1.13. Could anyone please advise on this? Thanks, Peng Xiao

Re: Massive deletes -> major compaction?

The major compaction is most efficient but can temporarily double (nearly) disk usage - if you can afford that, go for it. Alternatively you can do a user-defined compaction on each sstable in reverse generational order (oldest first) and as long as the data is minimally overlapping it’ll

Re: Massive deletes -> major compaction?

Have you considered the fantastic DeletingCompactionStrategy? https://github.com/protectwise/cassandra-util/tree/master/deleting-compaction-strategy > On Sep 21, 2017, at 11:51 AM, Jeff Jirsa

Re: Commitlog without header

https://issues.apache.org/jira/plugins/servlet/mobile#issue/CASSANDRA-11995 -- Jeff Jirsa > On Sep 19, 2017, at 4:36 PM, Dikang Gu wrote: > > Hello, > > In our production cluster, we had multiple times that after a *unclean* > shutdown, cassandra sever can not start

Massive deletes -> major compaction?

Cassandra version 2.0.17 (yes, it's old - waiting for new hardware/new OS to upgrade) In a long-running system with billions of rows, TTL was not set. So a one-time purge is being planned to reduce disk usage. Records older than a certain date will be deleted. The table uses size-tiered

The future: Java 9 and the disappearance of CLASSPATH

We're very new to Cassandra. We implement org.apache.index.Indexdropping a JAR containing our custom-index service into Cassandra's /lib/ subdirectory because this subdirectory is on the classpath. It's early days yet, but I thought I'd ask about the plans for Java 9 given that Jigsaw sort of

RE: network down between DCs

Hi, within the default hint window of 3 hours, the hinted handoff mechanism should take care of that, but we have seen that failing from time to time (depending on the load) in 2.1 with some sort of tombstone related issues causing failing requests on the system hints table. So, watch out any

Re: Drastic increase in disk usage after starting repair on 3.7

Hi Paul, This might be a long shot, but some repairs might fail to clear their snapshot (not sure if its still the case with C* 3.7 however, I had the problem on 2.X branche). What does nodetool listsnapshot indicate ? On 21 September 2017 at 05:49, kurt greaves wrote: >

network down between DCs

Hi there, We have two DCs for a Cassandra Cluster,if the network is down less than 3 hours(default hint window),with my understanding,it will recover automatically,right?Do we need to run repair manually? Thanks, Peng Xiao

Re: network down between DCs

Hi, That’s correct. You need to run repairs only after a node/DC/connection is down for more then max_hint_window_in_ms. Cheers, Hannu On 21 September 2017 at 11:30:44, Peng Xiao (2535...@qq.com) wrote: Hi there, We have two DCs for a Cassandra Cluster,if the network is down less than 3

Understanding Messages in the Debug.log

Good Morning Community, Can anyone help me understand what these messages (and I have a lot of them in the log) mean, they must be a symptom of something but I am unsure how to starting working this out. I'm using C* 3.0.11, CQL 5.0.1. I have 6 node ring over 2 DC's (3 in each DC) each of the

回复：RE: network down between DCs

Thanks Thomas for the reminder,we will watch the system log. -- 原始邮件 -- 发件人: "Steinmaurer, Thomas";; 发送时间: 2017年9月21日(星期四) 下午5:17 收件人: "user@cassandra.apache.org"; 主题: RE: network down between DCs