incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Freeman <8fo...@gmail.com>
Subject Re: insert performance (1.2.8)
Date Mon, 26 Aug 2013 22:17:39 GMT
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 keeping the wide rows 
less wide, or by spreading out over time inserts into a single row?  
Just don't know what you mean by "shuffling"?

On 08/26/2013 03:06 PM, Jake Luciani wrote:
> How are you inserting the data? Is it all partition at once?
>
> We've had the experience that shuffling the inserts across rows for 
> wide rows gave us "normal" insert rates.  When you mutate a entire 
> wide row at once it hits a bottleneck.
>
>
> On Mon, Aug 26, 2013 at 4:49 PM, Keith Freeman <8forty@gmail.com 
> <mailto:8forty@gmail.com>> wrote:
>
>     I can believe that I'm IO bound with the current disk
>     configuration, but that doesn't explain the CPU load does it?  If
>     I'm hitting a limit of disk performance, I should see a slowdown
>     but not the jump in CPU, right?
>
>
>     On 08/22/2013 11:52 AM, Nate McCall wrote:
>>     Given the backups in the flushing stages, I think you are IO
>>     bound. SSDs will work best for the data volume. Use rotational
>>     media for the commitlog as it is largely sequential.
>>
>>     Quick experiment: disable commit log on the keyspace and see if
>>     your test goes faster ("WITH DURABLE_WRITES = false" on keyspace
>>     creation).
>>
>>
>>     On Wed, Aug 21, 2013 at 5:41 PM, Keith Freeman <8forty@gmail.com
>>     <mailto:8forty@gmail.com>> wrote:
>>
>>         We have 2 partitions on the same physical disk for commit-log
>>         and data.  Definitely non-optimal, we're planning to install
>>         SSDs for the commit-log partition but don't have them yet.
>>
>>         Can this explain the high server loads?
>>
>>         On 08/21/2013 04:24 PM, Nate McCall wrote:
>>


Mime
View raw message