> Semi-lame post to this mailing list i guess :( I should have checked that > earlier No problems.
Cheers ----------------- Aaron Morton Freelance Cassandra Developer New Zealand @aaronmorton http://www.thelastpickle.com On 17/01/2013, at 11:50 PM, Reik Schatz <reik.sch...@gmail.com> wrote: > Cool feature, didn't know it existed. It turned however out that everything > works fine! There was a configuration error that duplicated a AWS sns->sqs > subscription, so we go twice the amount of data delivered to our application. > Semi-lame post to this mailing list i guess :( I should have checked that > earlier but major thanks for looking into this and replying. > > Cheers, > Reik > > > On Thu, Jan 17, 2013 at 4:28 AM, aaron morton <aa...@thelastpickle.com> wrote: > You *may* be seeing this https://issues.apache.org/jira/browse/CASSANDRA-2503 > > It was implemented in 1.1.0 but perhaps data in the original cluster is more > compacted than the new one. > > Are the increases for all CF's are just a few? > Do you have a work load of infrequent writes to rows followed by wide reads ? > > Cheers > > ----------------- > Aaron Morton > Freelance Cassandra Developer > New Zealand > > @aaronmorton > http://www.thelastpickle.com > > On 16/01/2013, at 6:23 AM, Reik Schatz <reik.sch...@gmail.com> wrote: > >> Hi, we are running a 1.1.6 (datastax) test cluster with 6 nodes. After the >> recent 1.2 release we have set up a second cluster - also having 6 nodes >> running 1.2 (datastax). >> >> They are now running in parallel. We noticed an increase in the number of >> writes in our monitoring tool (Datadog). The tool is using the write count >> statistic of nodetool cfstats. So we ran nodetool cfstats on one node in >> each cluster. To get an initial write count. Then we ran it again after 60 >> sec. It looks like the 1.2 received about twice the amount of writes. >> >> The way our application is designed is that the writes are idempotent, so we >> don't see a size increase. Were there any changes in between 1.1.6 > 1.2 >> that could explain this behavior? >> >> I know that 1.2 has the concept of virtual nodes, to spread out the data >> more evenly. So if the "write count" value was actually the sum of all >> writes to all nodes in the, this increase would make sense. >> >> Reik >> >> ps. the clusters are not 100% identical. i.e. since bloom filters are now >> off-heap, we changed settings for heap size and memtables. Cluster 1.1.6: >> heap 8G, memtables 1/3 of heap. Cluster 1.2.0: heap 4G, memtables 2G. Not >> sure it can have an impact on the problem. > >