Load reported from node tool ring is the live load, which means SSTables that the server has open and will read from during a request. This will include tombstones, expired and over written data.
nodetool ctstats also includes "dead" load, which is sstables that are in use but still on disk. Cheers ----------------- Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 20/01/2012, at 12:50 AM, Marcel Steinbach wrote: > 2012/1/19 aaron morton <aa...@thelastpickle.com>: >> If you have performed any token moves the data will not be deleted until you >> run nodetool cleanup. > We did that after adding nodes to the cluster. And then, the cluster > wasn't balanced either. > Also, does the "Load" really account for "dead" data, or is it just live data? > >> To get a baseline I would run nodetool compact to do major compaction and >> purge any tomb stones as others have said. > We will do that, but I doubt we have 450GB tomb stones on node 2... > >> Cheers >> >> ----------------- >> Aaron Morton >> Freelance Developer >> @aaronmorton >> http://www.thelastpickle.com >> >> On 18/01/2012, at 2:19 PM, Maki Watanabe wrote: >> >> Are there any significant difference of number of sstables on each nodes? >> >> 2012/1/18 Marcel Steinbach <marcel.steinb...@chors.de>: >> >> We are running regular repairs, so I don't think that's the problem. >> >> And the data dir sizes match approx. the load from the nodetool. >> >> Thanks for the advise, though. >> >> >> Our keys are digits only, and all contain a few zeros at the same >> >> offsets. I'm not that familiar with the md5 algorithm, but I doubt that it >> >> would generate 'hotspots' for those kind of keys, right? >> >> >> On 17.01.2012, at 17:34, Mohit Anchlia wrote: >> >> >> Have you tried running repair first on each node? Also, verify using >> >> df -h on the data dirs >> >> >> On Tue, Jan 17, 2012 at 7:34 AM, Marcel Steinbach >> >> <marcel.steinb...@chors.de> wrote: >> >> >> Hi, >> >> >> >> we're using RP and have each node assigned the same amount of the token >> >> space. The cluster looks like that: >> >> >> >> Address Status State Load Owns Token >> >> >> >> 205648943402372032879374446248852460236 >> >> >> 1 Up Normal 310.83 GB 12.50% >> >> 56775407874461455114148055497453867724 >> >> >> 2 Up Normal 470.24 GB 12.50% >> >> 78043055807020109080608968461939380940 >> >> >> 3 Up Normal 271.57 GB 12.50% >> >> 99310703739578763047069881426424894156 >> >> >> 4 Up Normal 282.61 GB 12.50% >> >> 120578351672137417013530794390910407372 >> >> >> 5 Up Normal 248.76 GB 12.50% >> >> 141845999604696070979991707355395920588 >> >> >> 6 Up Normal 164.12 GB 12.50% >> >> 163113647537254724946452620319881433804 >> >> >> 7 Up Normal 76.23 GB 12.50% >> >> 184381295469813378912913533284366947020 >> >> >> 8 Up Normal 19.79 GB 12.50% >> >> 205648943402372032879374446248852460236 >> >> >> >> I was under the impression, the RP would distribute the load more evenly. >> >> >> Our row sizes are 0,5-1 KB, hence, we don't store huge rows on a single >> >> node. Should we just move the nodes so that the load is more even >> >> distributed, or is there something off that needs to be fixed first? >> >> >> >> Thanks >> >> >> Marcel >> >> >> <hr style="border-color:blue"> >> >> >> <p>chors GmbH >> >> >> <br><hr style="border-color:blue"> >> >> >> <p>specialists in digital and direct marketing solutions<br> >> >> >> Haid-und-Neu-Straße 7<br> >> >> >> 76131 Karlsruhe, Germany<br> >> >> >> www.chors.com</p> >> >> >> <p>Managing Directors: Dr. Volker Hatz, Markus Plattner<br>Amtsgericht >> >> Montabaur, HRB 15029</p> >> >> >> <p style="font-size:9px">This e-mail is for the intended recipient only and >> >> may contain confidential or privileged information. If you have received >> >> this e-mail by mistake, please contact us immediately and completely delete >> >> it (and any attachments) and do not forward it or inform any other person of >> >> its contents. If you send us messages by e-mail, we take this as your >> >> authorization to correspond with you by e-mail. E-mail transmission cannot >> >> be guaranteed to be secure or error-free as information could be >> >> intercepted, amended, corrupted, lost, destroyed, arrive late or incomplete, >> >> or contain viruses. Neither chors GmbH nor the sender accept liability for >> >> any errors or omissions in the content of this message which arise as a >> >> result of its e-mail transmission. Please note that all e-mail >> >> communications to and from chors GmbH may be monitored.</p> >> >> >> >> >> >> >> -- >> w3m >> >>
