Thanks again guys, this has been a major blocker for us and I think we've
made some major progress with your advice.
We have gone ahead with Lerh's suggestion and the cluster is operating much
more smoothly while the new node compacts. We read at quorum, so in the
event that we don't make it withi
>
>
> Kurt - We're on 3.7, and our approach was to try thorttling compaction
> throughput as much as possible rather than the opposite. I had found some
> resources that suggested unthrottling to let it get it over with, but
> wasn't sure if this would really help in our situation since the I/O pip
Hi Paul,
Agh, I don't have any experience with sstableofflinerelevel. Maybe Kurt
does, sorry.
Also, if it wasn't obvious, to add back the node to the cluster once it is
done would be the 3 commands, with enable substituted for disable. It feels
like it will take some time to get through all the c
Unsubscribe
On Mon, Sep 11, 2017 at 4:48 PM, Paul Pollack
wrote:
> Hi,
>
> We run 48 node cluster that stores counts in wide rows. Each node is using
> roughly 1TB space on a 2TB EBS gp2 drive for data directory and
> LeveledCompactionStrategy. We have been trying to bootstrap new nodes that
> u
Thanks for the responses Lerh and Kurt!
Lerh - We had been considering those particular nodetool commands but were
hesitant to perform them on a production node without either testing
adequately in a dev environment or getting some feedback from someone who
knew what they were doing (such as yours
What version are you using? There are improvements to streaming with LCS in
2.2.
Also, are you unthrottling compaction throughput while the node is
bootstrapping?
Hi Paul,
The new node will certainly have a lot of compactions to deal with being
LCS. Have you tried performing the following on the new node once it has
joined?
*nodetool disablebinary && nodetool disablethrift && nodetooldisablegossip*
This will disconnect Cassandra from the cluster, but not
Hi,
We run 48 node cluster that stores counts in wide rows. Each node is using
roughly 1TB space on a 2TB EBS gp2 drive for data directory and
LeveledCompactionStrategy. We have been trying to bootstrap new nodes that
use a raid0 configuration over 2 1TB EBS drives to increase I/O throughput
cap f
Considering the (simplified) table that I wrote before:
create table data (
id bigint,
ts bigint,
column1 blob,
column2 blob,
column3 blob,
...
column29 blob,
column30 blob
primary key (id, ts)
A user request (varies every time) translates into a set of queries asking
a subset of the columns (< 1
What does your query actually look like today?
Is your non-EQ on timestamp selecting a single row a few rows or many rows
(dozens, hundreds, thousands)?
-- Jack Krupansky
On Sun, Feb 14, 2016 at 7:40 PM, Gianluca Borello
wrote:
> Thanks again.
>
> One clarification about "reading in a single
Thanks again.
One clarification about "reading in a single SELECT": in my point 2, I
mentioned the need to read a variable subset of columns every time, usually
in the range of ~5 out of 30. I can't find a way to do that in a single
SELECT unless I use the IN operator (which I can't, as explained)
You can definitely read all of columns in a single SELECT. And the
n-INSERTS can be batched and will insert fewer cells in the storage engine
than the previous approach.
-- Jack Krupansky
On Sun, Feb 14, 2016 at 7:31 PM, Gianluca Borello
wrote:
> Thank you for your reply.
>
> Your advice is def
Thank you for your reply.
Your advice is definitely sound, although it still seems suboptimal to me
because:
1) It requires N INSERT queries from the application code (where N is the
number of columns)
2) It requires N SELECT queries from my application code (where N is the
number of columns I n
You could add the column number as an additional clustering key. And then
you can actually use COMPACT STORAGE for even more efficient storage and
access (assuming there is only a single non-PK data column, the blob
value.) You can then access (read or write) an individual column/blob or a
slice o
Hi
I've just painfully discovered a "little" detail in Cassandra: Cassandra
touches all columns on a CQL select (related issues
https://issues.apache.org/jira/browse/CASSANDRA-6586,
https://issues.apache.org/jira/browse/CASSANDRA-6588,
https://issues.apache.org/jira/browse/CASSANDRA-7085).
My dat
replicate their
>> problem with these two statements
>>
>> INSERT INTO clocks (shard, clock) VALUES (?, ?)
>> UPDATE clocks SET clock = clock + ? WHERE shard = ?
>>
>> the first one should create range tombstones because it overwrites the
>> the map on e
ck = clock + ? WHERE shard = ?
>
> the first one should create range tombstones because it overwrites the the
> map on every insert, and the second should not because it adds to the map.
> neither of those seems to have any performance issues, at least not on
> inserts.
>
> and it'
p on every insert, and the second should not because it adds to the map.
neither of those seems to have any performance issues, at least not on
inserts.
and it's the slowdown on inserts that confuses me, both the stack overflow
questioners say that they saw a drop in insert performance. I never
Can you provide details of the mutation statements you are running ? The Stack
Overflow posts don't seem to include them.
Cheers
-
Aaron Morton
Freelance Cassandra Consultant
New Zealand
@aaronmorton
http://www.thelastpickle.com
On 27/06/2013, at 5:58 AM, Theo Hultberg wrote:
do I understand it correctly if I think that collection modifications are
done by reading the collection, writing a range tombstone that would cover
the collection and then re-writing the whole collection again? or is it
just the modified parts of the collection that are covered by the range
tombst
Hi,
I'm pretty sure that it's related to this ticket :
https://issues.apache.org/jira/browse/CASSANDRA-5677
I'd be happy if someone tests this patch.
It should apply easily on 1.2.5 & 1.2.6
After applying the patch, by default, the current implementation is still
used, but modify your cassandra.
Hi,
I've seen a couple of people on Stack Overflow having problems with
performance when they have maps that they continuously update, and in
hindsight I think I might have run into the same problem myself (but I
didn't suspect it as the reason and designed differently and by accident
didn't use m
ites
<http://www.similarsites.com/> | TopSite <http://www.topsite.com/>
From: Jonathan Ellis [mailto:jbel...@gmail.com]
Sent: Friday, June 03, 2011 2:41 AM
To: user@cassandra.apache.org
Subject: Re: Performance issues after upgrading to Cassandra 0.7.6-2 from
Cassandra 0.6.6
Where is th
Where is the bottleneck? See
http://spyced.blogspot.com/2010/01/linux-performance-basics.html
On Thu, Jun 2, 2011 at 11:18 AM, Nir Cohen wrote:
> Hi all,
>
> Recently we have upgraded our Cassandra servers to version 0.7.6-2 from
> 0.6.6
>
> We are experiencing a severe perfo
Hi all,
Recently we have upgraded our Cassandra servers to version 0.7.6-2 from
0.6.6
We are experiencing a severe performance issues - we must restart the
Cassandra servers every half hour (otherwise our apps servers can't connect
to the Cassandra servers).
Each Cassandra server has
Since you're using hector hector-users@ is a good place to be, so
u...@cassandra to bcc
operateWithFailover is one stop before sending the request over the network
and waiting, so it makes lots of sense that a significant part of the
application is spent in it.
On Tue, Jul 13, 2010 at 6:22 PM, Sa
Hi,
I have set up a ring with a couple of servers and wanted to run some
stress tests.
Unfortunately, there is some kind of bottleneck at the client side.
I'm using Hector and Cassandra 0.6.1.
The subsequent profile results are based on a small Java program that
inserts sequentially records, wit
27 matches
Mail list logo
