On 20/03/2017 02:35, S G wrote:
2)
https://docs.datastax.com/en/developer/java-driver/3.1/manual/statements/prepared/
tells me to avoid preparing select queries if I expect a change of
columns in my table down the road.
The problem is also related to select * which is considered bad practice
wit
we have a datacenter which is currently used exlusively for spark batch
jobs.
in case batch jobs are running against that environment we can see very
high peaks in blocked native transport requests (up to 10k / minute).
i am concerned because i guess that will slow other queries (in case
other ap
Did you check STW GCs?
You can do that with 'nodetool gcstats', by looking at the gc.log or
observing GC related JMX metrics.
2017-03-20 8:52 GMT+01:00 Roland Otta :
> we have a datacenter which is currently used exlusively for spark batch
> jobs.
>
> in case batch jobs are running against that e
well. i checked it now.
we have some stw collections from 100 to 200ms every 5 to 60 seconds.
i am not sure whether the blocked threads are related to that but anyway these
pauses are too long for low latency applications.
so i wil check gc tuning first and will check afterwards whether the bloc
Another thing.
Based on what I see in our system especially when I was changing from STCS to
LCS compaction strategy,
compaction does cause quite a bit of memory churn and it helps to increase heap
memory to certain extent.
You can see heap sizes using nodetool info to gauge your usage and hwm.
E
I would zero in on network throughput, especially interrack trunks
sent from my mobile
Daemeon Reiydelle
skype daemeon.c.m.reiydelle
USA 415.501.0198
On Mar 17, 2017 2:07 PM, "Roland Otta" wrote:
> hello,
>
> we are quite inexperienced with cassandra at the moment and are playing
> around with
Hi,
On Fri, Mar 17, 2017 at 2:22 PM Paulo Motta
wrote:
> It's safe to truncate this table since it's just used to inspect repairs
> for troubleshooting. You may also set a default TTL to avoid it from
> growing unbounded (this is going to be done by default on CASSANDRA-12701).
>
I've made an a
As secondary indexes are stored individually on each node what you're
suggesting sounds exactly like a consistency issue. the fact that you read
0 cells on one query implies the node that got the query did not have any
data for the row. The reason you would sometimes see different behaviours
is lik
default_time_to_live is a convenience parameter that automatically applies
a TTL to incoming data. Every field that's inserted can have a separate
TTL.
The TL;DR of all this is that changing default_time_to_live doesn't change
any existing data retroactively. You'd have to truncate the table if
Appreciate the reply, Kurt.
I sanitized it out of the traces, but all trace outputs listed the same
node for all three queries (1 working, 2 not working). Read repair chance
set to 0.0 as recommended when using TWCS.
I'll check tpstats - in this environment, load is not an issue, but network
issu
I'm trying to understand the maximum number of disk seeks required in a
read operation in Cassandra. I looked at several online articles including
this one:
https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlAboutReads.html
As per my understanding, two disk seeks are required in the worst
No dropped messages in tpstats on any of the nodes.
On Mon, Mar 20, 2017 at 3:11 PM, Voytek Jarnot
wrote:
> Appreciate the reply, Kurt.
>
> I sanitized it out of the traces, but all trace outputs listed the same
> node for all three queries (1 working, 2 not working). Read repair chance
> set to
On 2017-03-20 13:17 (-0700), preetika tyagi wrote:
> I'm trying to understand the maximum number of disk seeks required in a
> read operation in Cassandra. I looked at several online articles including
> this one:
> https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlAboutReads.html
>
Apologies for the stream-of-consciousness replies, but are the dropped
message stats output by tpstats an accumulation since the node came up, or
are there processes which clear and/or time-out the info?
On Mon, Mar 20, 2017 at 3:18 PM, Voytek Jarnot
wrote:
> No dropped messages in tpstats on an
Specifically, this puts us in an awkward position because LOCAL_QUORUM is
desirable so that we don't have unnecessary cross-DC traffic from the client by
default, but we can't use it because it will cause complete failure if the
local DC goes down. And we can't use QUORUM because it would fail i
I think the general assumption is that DC failover happens at the client
app level rather than the Cassandra level due to the potentially very
significant difference in request latency if you move from a app-local DC
to a remote DC. The preferred pattern for most people is that the app fails
in a f
I am trying to scrub a Column family using nodetool scrub, is it going to
create snapshots for sstables which are corrupted or for all the sstables
it is going to scrub ?? and to remove snapshots created does running
nodetool clearsnapshot is enough or do i need to manually delete pre-scrub
data f
On 20/03/2017 22:05, Michael Wojcikiewicz wrote:
Not sure if someone has suggested this, but I believe it's not
sufficient to simply add nodes to a cluster to increase read
performance: you also need to alter the ReplicationFactor of the
keyspace to a larger value as you increase your cluster get
Hi,
youre right – one seek with hit in the partition key cache and two if not.
Thats the theory – but two thinge to mention:
First, you need two seeks per sstable not per entire read. So if you data is
spread over multiple sstables on disk you obviously need more then two reads.
Think of often
Kairosdb (OpenTSDB clone forCassandra) is a TSDB that does this.
MAy be you could have a look at it ?
It has a daemon process that collects and groups data points into blobs
before writing to cassandra.
--
best,
Alain
20 matches
Mail list logo
