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 <mlars...@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 > >
