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 Thu, 25 Oct 2012 01:05:13 GMT
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 ?
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 ? 


Cheers

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

On 25/10/2012, at 11:26 AM, Mattias Larsson <mlarsson@yahoo-inc.com> wrote:

> 
> I'm testing various scenarios in a multi data center configuration. The setup is 10 Cassandra
1.1.5 nodes configured into two data centers, 5 nodes in each DC (RF DC1:3,DC2:3, write consistency
LOCAL_QUORUM). I have a synthetic random data generator that I can run, and each run adds
roughly 1GiB of data to each node per run,
> 
> DC          Rack        Status State   Load            Effective-Ownership
> 
> DC1         RAC1        Up     Normal  1010.71 MB      60.00%             
> DC2         RAC1        Up     Normal  1009.08 MB      60.00%             
> DC1         RAC1        Up     Normal  1.01 GB         60.00%             
> DC2         RAC1        Up     Normal  1 GB            60.00%             
> DC1         RAC1        Up     Normal  1.01 GB         60.00%             
> DC2         RAC1        Up     Normal  1014.45 MB      60.00%             
> DC1         RAC1        Up     Normal  1.01 GB         60.00%             
> DC2         RAC1        Up     Normal  1.01 GB         60.00%             
> DC1         RAC1        Up     Normal  1.01 GB         60.00%             
> DC2         RAC1        Up     Normal  1.01 GB         60.00%             
> 
> Now, if I kill all the nodes in DC2, and run the data generator again, I would expect
roughly 2GiB to be added to each node in DC1 (local replicas + hints to other data center),
instead I get this:
> 
> DC          Rack        Status State   Load            Effective-Ownership
> 
> DC1         RAC1        Up     Normal  17.56 GB        60.00%             
> DC2         RAC1        Down   Normal  1009.08 MB      60.00%             
> DC1         RAC1        Up     Normal  17.47 GB        60.00%             
> DC2         RAC1        Down   Normal  1 GB            60.00%             
> DC1         RAC1        Up     Normal  17.22 GB        60.00%             
> DC2         RAC1        Down   Normal  1014.45 MB      60.00%             
> DC1         RAC1        Up     Normal  16.94 GB        60.00%             
> DC2         RAC1        Down   Normal  1.01 GB         60.00%             
> DC1         RAC1        Up     Normal  17.26 GB        60.00%             
> DC2         RAC1        Down   Normal  1.01 GB         60.00%             
> 
> Checking the sstables on a node reveals this,
> 
> -bash-3.2$ du -hs HintsColumnFamily/
> 16G	HintsColumnFamily/
> -bash-3.2$
> 
> So it seems that what I would have expected to be 1GiB of hints is much larger in reality,
a 15x-16x inflation. This has a huge impact on write performance as well.
> 
> If I bring DC2 up again, eventually the load will drop down and even out to 2GiB across
the entire cluster.
> 
> I'm wondering if this inflation is intended or if it is possibly a bug or something I'm
doing wrong? Assuming this inflation is correct, what is the best way to deal with temporary
connectivity issues with a second data center? Write performance is paramount in my use case.
A 2x-3x overhead is doable, but not 15x-16x.
> 
> Thanks,
> /dml
> 
> 


Mime
View raw message