It's interesting and a bit surprising that 256 write threads isn't enough.
Even with a lot of cores, I'd expect you to be able to saturate CPU with
that many threads. I'd make sure you don't have other bottlenecks, like
GC, IOPs, network, or "microbursts" where your load is actually fluctuating
Hi,
We are testing Cassandra 3.11.2 and we sawed that it contains a critcal
bug wich was fixed in 3.11.3 (
https://issues.apache.org/jira/browse/CASSANDRA-13929).
After about 1 months of testing, we haven't encountered this bug in our
environnement, but to be sure before going in production, we
Hi, this node isn't in system.peers on both nodes.
On Thursday, September 6, 2018 10:02 PM, Michael Shuler
wrote:
On 09/06/2018 01:48 PM, Vlad wrote:
> Hi,
> 3 node cluster, Cassandra 3.9, GossipingPropertyFileSnitch, one DC
>
> I removed dead node with `nodetool assassinate`. It was
Hi,
this node isn't in system.peers on both nodes.
On Wednesday, August 29, 2018 4:22 PM, Vlad
wrote:
Hi,
>You'll need to disable the native transportWell, this is what I did already,
>it seems repair is running
I'm not sure whether repair will finish within 3 hours, but I can run it
On 09/06/2018 01:48 PM, Vlad wrote:
> Hi,
> 3 node cluster, Cassandra 3.9, GossipingPropertyFileSnitch, one DC
>
> I removed dead node with `nodetool assassinate`. It was also seed node,
> so I removed it from seeds list on two other nodes and restarted them.
>
> But I still see in log
> `DEBUG
Hi,3 node cluster, Cassandra 3.9, GossipingPropertyFileSnitch, one DC
I removed dead node with `nodetool assassinate`. It was also seed node, so I
removed it from seeds list on two other nodes and restarted them.
But I still see in log
`DEBUG [GossipTasks:1] 2018-09-06 18:32:05,149
Hello Folks,
Does any body refer good documentation on Cassandra stress test.
I have below questions.
1) Which server is good to start the test, Cassandra server or Application
server.
2) I am using Datastax Java driver, is any good documentation for stress test
specific to this driver.
3)
Hi all,
We are fairly new to Cassandra. We began looking into the CDC feature
introduced in 3.0. As we spent more time looking into it, the complexity
began to add up (i.e. duplicated mutation based on RF, out of order
mutation, mutation does not contain full row of data, etc). These
limitations
Remove my email please
De: Vitali Dyachuk [mailto:vdjat...@gmail.com]
Enviada em: quinta-feira, 6 de setembro de 2018 08:00
Para: user@cassandra.apache.org
Assunto: Re: Large sstables
What i have done is:
1) added more disks, so the compaction will carry on
2) when i've switched to LCS
Here is the stacktrace from the failure, it looks like it's trying to
gather all the columfamily metrics and going OOM. Is this just for the JMX
metrics?
https://github.com/apache/cassandra/blob/cassandra-2.1.16/src/java/org/apache/cassandra/metrics/ColumnFamilyMetrics.java
ERROR
We are receiving following error
9140- at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
[apache-cassandra-3.0.10.jar:3.0.10]
9141- at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101]
9142:WARN [SharedPool-Worker-1] 2018-09-06 14:29:46,071
Thank you Jeff.
While migration , how can test/validate against Cassandra particularly i am
going for "parallel run". Any sample strategy?
Regards,
Shyam
On Thu, 6 Sep 2018, 09:48 Jeff Jirsa, wrote:
> It very much depends on your application. You'll PROBABLY want to double
> write for some
What i have done is:
1) added more disks, so the compaction will carry on
2) when i've switched to LCS from STCS the STCS queues for the processing
big sstables have remained, so i've stopped these queues with nodetool stop
-id queue_id
and LCS compaction has started to process sstables , i'm
Alain,
compaction throughput is set to 32.
Regards,
Thomas
From: Alain RODRIGUEZ
Sent: Donnerstag, 06. September 2018 11:50
To: user cassandra.apache.org
Subject: Re: nodetool cleanup - compaction remaining time
Hello Thomas.
Be aware that this behavior happens when the compaction
>
> As far as I can remember, if you have unthrottled compaction, then the
> message is different: it says "n/a".
Ah right!
I am now completely convinced this needs a JIRA as well (indeed, if it's
not fixed in C*3+, as Jeff mentioned).
Thanks for the feedback Alex.
Le jeu. 6 sept. 2018 à
On Thu, Sep 6, 2018 at 11:50 AM Alain RODRIGUEZ wrote:
>
> Be aware that this behavior happens when the compaction throughput is set
> to *0 *(unthrottled/unlimited). I believe the estimate uses the speed
> limit for calculation (which is often very much wrong anyway).
>
As far as I can
IMHO, Cassandra write is more of a CPU bound task, so while determining cluster
write throughput, what CPU usage percent (avg among all cluster nodes) should
be determined as limit? Rephrase: what's the normal CPU usage in Cassandra
cluster (while no compaction, streaming or heavy-read
Hello Thomas.
Be aware that this behavior happens when the compaction throughput is set
to *0 *(unthrottled/unlimited). I believe the estimate uses the speed limit
for calculation (which is often very much wrong anyway).
I just meant to say, you might want to make sure that it's due to cleanup
Thank you so much Andrew. I will start reading it.
On Thu, 6 Sep 2018, 10:26 Andrew Baker, wrote:
> Hi Shyam,
>
> Those are big questions! The book *Cassandra: The Definitive Guide *is
> a good place to start, it will walk you through a little bit of each of
> those questions. It should be a
19 matches
Mail list logo
