cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aaron morton <aa...@thelastpickle.com>
Subject Re: Hinted Handoff storage inflation
Date Mon, 29 Oct 2012 08:12:50 GMT
> With both data centers functional, the test takes just a few minutes to run, with one
data center down, 15x the amount of time.
Could you provide the numbers, it's easier to get a feel for how the throughput is dropping.
Does latency reported by nodetool cf stats change ? 
I'm also interested to know how long hints were collected for. 

Each coordinator will be writing three hints, which will be slowing down the other writes
it needs to do. 

> but I found that the storage overhead was the same regardless of the size of the batch
mutation (i.e., 5 vs 25 mutations made no difference).
Batch size makes no difference. Each row mutation is treated as an individual command, the
batch is simply a way to reduce network calls. 

> Each write is new data only (no overwrites). Each mutation adds a row to one column family
with a column containing about ~100 bytes of data and a new row to another column family with
a SuperColumn containing 2x17KiB payloads.
I cannot remember anyone raising this sort of issue about HH before. It may be that no one
has looked at how that level of hints is handled. 
Could you reproduce the problem with a smaller test case ? 

Cheers

-----------------
Aaron Morton
Freelance Developer
@aaronmorton
http://www.thelastpickle.com

On 27/10/2012, at 7:56 AM, Mattias Larsson <mlarsson@yahoo-inc.com> wrote:

> 
> On Oct 24, 2012, at 6:05 PM, aaron morton wrote:
> 
>> Hints store the columns, row key, KS name and CF id(s) for each mutation to each
node. Where an executed mutation will store the most recent columns collated with others under
the same row key. So depending on the type of mutation hints will take up more space. 
>> 
>> The worse case would be lots of overwrites. After that writing a small amount of
data to many rows would result in a lot of the serialised space being devoted to row keys,
KS name and CF id.
>> 
>> 16Gb is a lot though. What was the write workload like ?
> 
> Each write is new data only (no overwrites). Each mutation adds a row to one column family
with a column containing about ~100 bytes of data and a new row to another column family with
a SuperColumn containing 2x17KiB payloads. These are sent in batches with several in them,
but I found that the storage overhead was the same regardless of the size of the batch mutation
(i.e., 5 vs 25 mutations made no difference). A total of 1,000,000 mutations like these are
sent over the duration of the test.
> 
> 
>> You can get an estimate on the number of keys in the Hints CF using nodetool cfstats.
Also some metrics in the JMX will tell you how many hints are stored. 
>> 
>>> This has a huge impact on write performance as well.
>> Yup. Hints are added to the same Mutation thread pool as normal mutations. They are
processed async to the mutation request but they still take resources to store. 
>> 
>> You can adjust how long hints a collected for with max_hint_window_in_ms in the yaml
file. 
>> 
>> How long did the test run for ? 
>> 
> 
> With both data centers functional, the test takes just a few minutes to run, with one
data center down, 15x the amount of time.
> 
> /dml
> 
> 


Mime
View raw message