Re: cassandra full gc too often

On Sun, Jan 3, 2016 at 5:54 PM, Shuo Chen wrote: > There are client operation in these days. Besides most columnfamily in the > cluster are supercolumnfamily created by cassandra-cli. Most rows have > average 30 sub-rows and each sub-row has 20 columns. > Supercolumns,

Re: compaction_throughput_mb_per_sec

This is set in the cassandra.yaml on each node independently; it doesn't have to be same cluster-wide. On Mon, Jan 4, 2016 at 3:59 PM, Ken Hancock wrote: > I was surprised the other day to discover that this was a cluster-wide > setting. Why does that make sense? > >

When many sstables(thousand) in level 0 ，compaction very slow

After I use sstableloader from a old cluster, the new cluster node's data size double. The new cluster has the same node with old cluster( 3 nodes). The old cluster has 500G each node,after sstableloader completely, the new cluster data size nearly 1T each node. The problem is that

Re: Cassandra Java Driver

Trying to connect to C* v3.1.1 cluster. It works nice with cqlsh /$ cqlsh// //Connected to Test Cluster at 127.0.0.1:9042.// //[cqlsh 5.0.1 | Cassandra 3.1.1 | CQL spec 3.3.1 | Native protocol v4]/ But doesn't work with /cassandra-driver-core/. I use next mvn deps: /// //

Re: compaction_throughput_mb_per_sec

Why do you think it’s cluster wide? That param is per-node, and you can change it at runtime with nodetool (or via the JMX interface using jconsole to ip:7199 ) From: Ken Hancock Reply-To: "user@cassandra.apache.org" Date: Monday, January 4, 2016 at 12:59 PM To:

Announcement: Thrift API deprecation

Thrift has been officially frozen for almost two years and unofficially for longer. Meanwhile, maintaining Thrift support through changes like 8099 has been a substantial investment. Thus, we are officially deprecating Thrift now and removing support in 4.0, i.e. Nov 2016 if tick-tock goes as

Re: compaction_throughput_mb_per_sec

> >> Also, as I increase my node count, I technically also have to increase my >> compaction_throughput which would require a rolling restart across the >> cluster. >> >> > You can set compaction throughput on each node dynamically via nodetool > setcompactionthroughput. > > > Also, the IOPS

Re: Data Modeling: Partition Size and Query Efficiency

You should endeavor to use a repeatable method of segmenting your data. Swapping partitions every time you "fill one" seems like an anti pattern to me. but I suppose it really depends on what your primary key is. Can you share some more information on this? In the past I have utilized the

Re: memory usage problem of Metadata.tokenMap.tokenToHost

There are still a couple of tickets being worked on for 2.1.10 and the release will come afterwards. You can check the list: https://datastax-oss.atlassian.net/browse/JAVA-989?jql=project%20%3D%20JAVA%20AND%20fixVersion%20%3D%202.1.10 On Mon, Jan 4, 2016 at 5:57 AM, joseph gao

Re:Re: Fail to export all data in C* cluster

Dear Jack, Thanks! My keyspace is such as: test@cqlsh> DESC KEYSPACE sky ; CREATE KEYSPACE sky WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '3'} AND durable_writes = true; CREATE TABLE sky.user1 (pati int, uuid text, name text, name2 text, PRIMARY KEY (pati,

Fail to export all data in C* cluster

Hi all, I have a C* cluster with 6 nodes. My cassandra version is 2.1.1. I start 50 threads to insert datas into C* cluster, each thread inserts about up to 100 million rows with the same partition key. After inserting all the datas, I start another app with 50 threads to export all the

Re: Best way to get Cassandra status in Bash

(Hit enter too fast) In particular, `nodetool status` will give you a summary of the status of the cluster. See the documentation for the parameters it takes. -kr, Gerard. On Mon, Jan 4, 2016 at 3:49 PM, Gerard Maas wrote: > I think you are looking for the nodetool

Data Modeling: Partition Size and Query Efficiency

A problem that I have run into repeatedly when doing schema design is how to control partition size while still allowing for efficient multi-row queries. We want to limit partition size to some number between 10 and 100 megabytes to avoid operational issues. The standard way to do that is to

Re: Best way to get Cassandra status in Bash

Hello Gerard, thanks for your reply. It seems nodetool works only when the cluster is up and running. In case of a bad startup of Cassandra, if I run "nodetool status" I get one of these 2 errors: 1) error: No nodes present in the cluster. Has this node finished starting up? -- StackTrace

Re: Best way to get Cassandra status in Bash

I think you are looking for the nodetool utility: https://docs.datastax.com/en/cassandra/2.1/cassandra/tools/toolsNodetool_r.html On Mon, Jan 4, 2016 at 1:47 PM, Giovanni Usai wrote: > Hello, > I would gladly welcome the help of the community on the following issue

Re: Fail to export all data in C* cluster

You have three choices: 1. Insert with CL=ALL, with client-level retries if the write fails due to the cluster being overloaded. 2. Insert with CL=QUORUM and then run repair after all data has been inserted. 3. Lower your insert rate in your client so that the cluster can keep up with your

Re: compaction_throughput_mb_per_sec

> > > Also, as I increase my node count, I technically also have to increase my > compaction_throughput which would require a rolling restart across the > cluster. > > You can set compaction throughput on each node dynamically via nodetool setcompactionthroughput. -- - Nate

Re: Best way to get Cassandra status in Bash

Hi Giovanni, You could use netcat (nc) to test that the cassandra port is up and use a timeout to decide when to take an action nc -z localhost 9160 check for the exit code to decide what action to take. -kr, Gerard. On Mon, Jan 4, 2016 at 4:56 PM, Giovanni Usai