If you see the new node as JOINING state ( cannot remember what that is in
> nodetool status) you should be ok to go.
>
> Cheers
>
>
> -
> Aaron Morton
> New Zealand
> @aaronmorton
>
> Co-Founder & Principal Consultant
> Apache Cassandra Cons
Hi.
Here
http://www.datastax.com/documentation/cassandra/1.2/webhelp/cassandra/operations/ops_add_node_to_cluster_t.html
says
that it is needed to wait 2 minutes between adding nodes.
I was trying to figure out why, and how to check if after 2 minutes the
conditions to add more nodes are met or I
On Fri, Nov 26, 2010 at 1:34 PM, Edward Capriolo wrote:
> I believe there is room for other compaction models. I am interested
> in systems that can optimize the case with multiple data directories
> for example. It seems like from my experiment a major compaction can
> not fully utilize hardware
On Thu, Nov 25, 2010 at 9:09 PM, Peter Schuller
wrote:
>> My total data size is 2TB
>
> For the entire cluster? (I realized I was being ambiguous, I meant per node.)
Yes, for the entire cluster.
Regarding the multithreaded compaction, I'll look into the code and do
my best. I think that compactio
> When you say that it grows constantly, does that mean up to 30 or even
> farther?
My total data size is 2TB
Actually, I never see the count stable. When it reached 30 I thinked
"I am reaching the default upper limit for a compaction, something
went wrong" and I went back to 1GB memtables (also
Thank you very much you both Jonathan and Peter.
I will upgrade.
However, the point has to do with the fact Peter mentions. With smaller
memtables I see that minor compaction is unable to keep up with the writes.
The number of sstables grows constantly during my peaks hours. With 400MB
memtables
Hello All.
I am facing a (capacity?) problem in my eight nodes cluster running 0.6.2
patched with CASSANDRA-1014 and CASSANDRA-699.
I have 200 writes/second on peaks (on each node, taking into account
replication), with arow size of 35kb. I configured the memtable size to 1GB,
the biggest size
On Tue, Jul 20, 2010 at 8:20 PM, Dathan Pattishall wrote:
> No did not copy the data directories from one node to another. This
> data is new data, newly created from scratch.
>
I ussualy see this behaviour after a node shutdown/startup but it
tends to disappear over time (sometimes over 24 hours
On Thu, Jul 15, 2010 at 2:01 PM, Jonathan Ellis wrote:
> The main problem is not the syscall so much as Java insisting on
> zeroing out any buffer you create, which is a big hit to performance
> when you're allocating buffers for file i/o on each request instead of
> just mmaping things. Re-using
On Tue, Jul 6, 2010 at 8:13 PM, Matt Su wrote:
> This thread make us raised a concern: we choose Cassandra because
> FB,Twitter,Digg are using them, and we’re doubting whether Cassandra is
> definitely trustable.
If cassandra is definitely trustable is something that you have to
find by yourself,
On Mon, May 24, 2010 at 7:43 PM, Jonathan Ellis wrote:
> with C# you need to be sure to tell thrift to use client-side
> buffering. http://wiki.apache.org/cassandra/ThriftExamples#C.23 shows
> this (but didn't until recently)
Yes, I am unsing TBufferedTransport. However the high times continues.
I have the same issue in my cluster: 0,5% of requests are extremely
slow because the time it takes to read the data from the socket.
However in my case it is not related to the load. Actually the
percentage of anomalies drop as the load increases.
On the other hand the nio is actually slow than b
As far as i know, the tbuffered/tsocket issue only applies to c# (btw,
que had a lot of problems with hector#). In java, the class
tbufferedtransport doenst exist.
Carlos
On 5/10/10, Arie Keren wrote:
> Using TSocket without TBufferedTransport hurts performance.
>
> See
> http://mail-archives
Are you using TSocket in the client?. If yes, use TbufferedTransport instead.
Carlos
On 4/29/10, Viktor Jevdokimov wrote:
> Thrift C# sources, thrift generated Cassandra sources, test app built with
> C#. Simple connect/write/read operations. No pooling or anything else.
>
> From: Heath Oderman
On Sat, Apr 24, 2010 at 10:59 PM, Jonathan Ellis wrote:
> No, Framed is totally different.
You are right. Seeing both, the java and c# thrift code, I think that
there is no need to use other transport than TSocket in Java because
it seems to be using buffered stream in the TSocket implementation.
On Sat, Apr 24, 2010 at 8:00 PM, Joost Ouwerkerk wrote:
> TBufferedTransport seems to be missing from the Java library bundled with
> cassandra-bin (0.6.1)...
I think is TFramedTransport in Java.
BTW, I ran the test and I saw enomous improvement in performance (a
1/30 of the original time).
Don
On Fri, Apr 23, 2010 at 4:29 PM, Heath Oderman wrote:
> Really interesting find.
> After Jonathan E. suggested py_stress and it seemed clear the problem was in
> my .net client I spent a few days debugging the client in detail.
> I ended up changing my CassandraContext instantiation to use a
>
17 matches
Mail list logo
