That sounds interesting, but not sure exactly what you mean? My key is
like this: "((f1, f2, day) timeuuid)", and f1/f2 are roughly
well-distributed. So my inserts are pretty evenly distributed across
about 22k combinations of f1+f2 each day.
Are you saying that you get better performance by
What's the disk setup like on these system? You have some pending tasks in
MemtablePostFlusher and FlushWriter which may mean there is contention on
flushing discarded segments from the commit log.
On Wed, Aug 21, 2013 at 5:14 PM, Keith Freeman <8fo...@gmail.com> wrote:
> Ok, I tried batching 5
The only thing I can think to suggest at this point is upping that batch
size - say to 500 and see what happens.
Do you have any monitoring on this cluster? If not, what do you see as the
output of 'nodetool tpstats' while you run this test?
On Wed, Aug 21, 2013 at 1:40 PM, Keith Freeman <8fo...
Building the giant batch string wasn't as bad as I thought, and at first
I had great(!) results (using "unlogged" batches): 2500 rows/sec
(batches of 100 in 48 threads) ran very smoothly, and the load on the
cassandra server nodes averaged about 1.0 or less continuously.
But then I upped it to
Thrift will allow for more large, free-form batch contstruction. The
increase will be doing a lot more in the same payload message. Otherwise
CQL is more efficient.
If you do build those giant string, yes you should see a performance
improvement.
On Tue, Aug 20, 2013 at 8:03 PM, Keith Freeman <8
Thanks. Can you tell me why would using thrift would improve performance?
Also, if I do try to build those giant strings for a prepared batch
statement, should I expect another performance improvement?
On 08/20/2013 05:06 PM, Nate McCall wrote:
Ugh - sorry, I knew Sylvain and Michaël had wor
Ugh - sorry, I knew Sylvain and Michaël had worked on this recently but it
is only in 2.0 - I could have sworn it got marked for inclusion back into
1.2 but I was wrong:
https://issues.apache.org/jira/browse/CASSANDRA-4693
This is indeed an issue if you don't know the column count before hand (or
So I tried inserting prepared statements separately (no batch), and my
server nodes load definitely dropped significantly. Throughput from my
client improved a bit, but only a few %. I was able to *almost* get
5000 rows/sec (sort of) by also reducing the rows/insert-thread to 20-50
and elimin
AFAIK, batch prepared statements were added just recently:
https://issues.apache.org/jira/browse/CASSANDRA-4693 and many client
libraries are not supporting it yet. (And I believe that the problem is
related to batch operations).
On Tue, Aug 20, 2013 at 4:43 PM, Nate McCall wrote:
> Thanks for
Thanks for putting this up - sorry I missed your post the other week. I
would be real curious as to your results if you added a prepared statement
for those inserts.
On Tue, Aug 20, 2013 at 9:14 AM, Przemek Maciolek wrote:
> I had similar issues (sent a note on the list few weeks ago but nobody
I had similar issues (sent a note on the list few weeks ago but nobody
responded). I think there's a serious bottleneck with using wide rows and
composite keys. I made a trivial benchmark, which you check here:
http://pastebin.com/qAcRcqbF - it's written in cql-rb, but I ran the test
using astyana
John makes a good point re:prepared statements (I'd increase batch sizes
again once you did this as well - separate, incremental runs of course so
you can gauge the effect of each). That should take out some of the
processing overhead of statement validation in the server (some - that load
spike st
Ok, I'll try prepared statements. But while sending my statements
async might speed up my client, it wouldn't improve throughput on the
cassandra nodes would it? They're running at pretty high loads and only
about 10% idle, so my concern is that they can't handle the data any
faster, so some
I'd suggest using prepared statements that you initialize at application
start up and switching to use Session.executeAsync coupled with Google
Guava Futures API to get better throughput on the client side.
On Mon, Aug 19, 2013 at 10:14 PM, Keith Freeman <8fo...@gmail.com> wrote:
> Sure, I've t
Sure, I've tried different numbers for batches and threads, but
generally I'm running 10-30 threads at a time on the client, each
sending a batch of 100 insert statements in every call, using the
QueryBuilder.batch() API from the latest datastax java driver, then
calling the Session.execute() f
How big are the batch sizes? In other words, how many rows are you sending
per insert operation?
Other than the above, not much else to suggest without seeing some example
code (on pastebin, gist or similar, ideally).
On Mon, Aug 19, 2013 at 5:49 PM, Keith Freeman <8fo...@gmail.com> wrote:
> I'v
I've got a 3-node cassandra cluster (16G/4-core VMs ESXi v5 on 2.5Ghz
machines not shared with any other VMs). I'm inserting time-series data
into a single column-family using "wide rows" (timeuuids) and have a
3-part partition key so my primary key is something like ((a, b, day),
in-time-uuid
Definitely multi thread writes...probably with a little batching (10 or so).
That's how i get my peak throughput.
Le 23 févr. 2012 04:48, "Deno Vichas" a écrit :
> all,
>
> would i be better off (i'm in java land) with spawning a bunch of
> threads that all add a single item to a mutator or a sin
all,
would i be better off (i'm in java land) with spawning a bunch of
threads that all add a single item to a mutator or a single thread that
adds a bunch of items to a mutator?
thanks,
deno
Are your test client talks to single node or to both ?
On Mon, Feb 28, 2011 at 2:05 PM, Flachbart, Dirk (HP Software -
TransactionVision) wrote:
> Replication factor is set to 1, and I'm using ConsistencyLevel.ANY. And yep,
> I tried doubling the threads from 16 to 32 when running with the second
> server, didn't make a difference.
>
> Regarding the
> Replication factor is set to 1, and I'm using ConsistencyLevel.ANY. And yep,
> I tried doubling the threads from 16 to 32 when running with the second
> server, didn't make a difference.
Are you sure the client isn't the bottleneck? Have you tried running
the client on independent (and perhaps
user@cassandra.apache.org
Cc: Ryan King; Flachbart, Dirk (HP Software - TransactionVision)
Subject: Re: Question about insert performance in multiple node cluster
> What's your replication factor? Which consistency level are you using?
> Is the ring evenly balanced? Did you double the
onday, February 28, 2011 12:30 PM
To: user@cassandra.apache.org
Cc: Flachbart, Dirk (HP Software - TransactionVision)
Subject: Re: Question about insert performance in multiple node cluster
On Mon, Feb 28, 2011 at 9:24 AM, Flachbart, Dirk (HP Software -
TransactionVision) wrote:
> Hi,
>
&
> What's your replication factor? Which consistency level are you using?
> Is the ring evenly balanced? Did you double the number of client
> threads when you added the second server?
And are you on 100 mbit networking? 9k requests/second inserting 1k,
sounds suspiciously close to saturating 100 M
running the test driver with the local Cassandra server.
>
>
>
> Then I set up a cluster with both machines, and ran the same test again (the
> test driver is still local to one of the Cassandra nodes). Surprisingly I
> did not see any improvement in the insert performance, I got
driver is still local to one of the Cassandra nodes). Surprisingly I did
not see any improvement in the insert performance, I got the same 9000
inserts/sec as when running with a single node. I know that I shouldn't expect
linear scaling to 18,000 operations/sec, but shouldn't I see at
this behavior as well with 0.6, heap usage graphs look almost
>>> identical. The GC is a noticeable bottleneck, we’ve tried jdku19 and jrockit
>>> vm’s. It basically kills any kind of soft real time behavior.
>>>
>>>
>>>
>>> *From:* Masood Mortazavi [mailto:masood
noticeable bottleneck, we’ve tried jdku19 and jrockit
>> vm’s. It basically kills any kind of soft real time behavior.
>>
>>
>>
>> *From:* Masood Mortazavi [mailto:masoodmortaz...@gmail.com]
>> *Sent:* Monday, April 19, 2010 4:15 AM
>> *To:* user@cassandra.
Monday, April 19, 2010 4:15 AM
> *To:* user@cassandra.apache.org; d...@cassandra.apache.org
> *Subject:* 0.6 insert performance Re: [RELEASE] 0.6.1
>
>
>
> I wonder if anyone can use:
>
> * Add logging of GC activity (CASSANDRA-813)
> to confirm this:
> http://www.slidesh
It's hard to tell from those slides, but it looks like the slowdown
doesn't hit until after several GCs.
Perhaps this is compaction kicking in, not GCs? Definitely the extra
I/O + CPU load from compaction will cause a drop in throughput.
On Mon, Apr 19, 2010 at 6:14 AM, Masood Mortazavi
wrote:
l 19, 2010 4:15 AM
To: user@cassandra.apache.org; d...@cassandra.apache.org
Subject: 0.6 insert performance Re: [RELEASE] 0.6.1
I wonder if anyone can use:
* Add logging of GC activity (CASSANDRA-813)
to confirm this:
http://www.slideshare.net/schubertzhang/cassandra-060-insert-throughput
ere things work out.
From: Masood Mortazavi [mailto:masoodmortaz...@gmail.com]
Sent: Monday, April 19, 2010 6:15 AM
To: user@cassandra.apache.org; d...@cassandra.apache.org
Subject: 0.6 insert performance Re: [RELEASE] 0.6.1
I wonder if anyone can use:
* Add logging of GC activity (CASSAND
I wonder if anyone can use:
* Add logging of GC activity (CASSANDRA-813)
to confirm this:
http://www.slideshare.net/schubertzhang/cassandra-060-insert-throughput
- m.
On Sun, Apr 18, 2010 at 6:58 PM, Eric Evans wrote:
>
> Hot on the trails of 0.6.0 comes our latest, 0.6.1. This stable point
34 matches
Mail list logo
