Hi Peter That was precisely it. Thank you :)
Doing a major compaction on the heaviest node (74.65GB) reduced it to 33.55GB. I'll compact the other 2 nodes as well. I anticipate they will also settle around that size. On 2011-07-22, at 5:00 PM, Peter Tillotson wrote: > I'm not sure if this is the answer, but major compaction on each node > for each column family. I suspect the data shuffle has left quite a few > deleted keys which may get cleaned out on major compaction. As I > remember major compaction doesn't automatically in 7.x, I'm not sure if > it is triggered by repair. > > p > > On 22/07/11 16:08, Mina Naguib wrote: >> >> I'm trying to balance Load ( 41.98GB vs 59.4GB vs 74.65GB ) >> >> Owns looks ok. They're all 33.33% which is what I want. It was calculated >> simply by 2^127 / num_nodes. The only reason the first one doesn't start at >> 0 is that I''ve actually carved the ring planning for 9 machines (2 new data >> centers of 3 machines each). However only 1 data center (DCMTL) is >> currently up. >> >> >> On 2011-07-22, at 10:56 AM, Sasha Dolgy wrote: >> >>> are you trying to balance "load" or "owns" ? "owns" looks fine ... >>> 33.33% each ... which to me says balanced. >>> >>> how did you calculate your tokens? >>> >>> >>> On Fri, Jul 22, 2011 at 4:37 PM, Mina Naguib >>> <mina.nag...@bloomdigital.com> wrote: >>>> >>>> Address Status State Load Owns Token >>>> xx.xx.x.105 Up Normal 41.98 GB 33.33% >>>> 37809151880104273718152734159085356828 >>>> xx.xx.x.107 Up Normal 59.4 GB 33.33% >>>> 94522879700260684295381835397713392071 >>>> xx.xx.x.18 Up Normal 74.65 GB 33.33% >>>> 151236607520417094872610936636341427313 >> >> >
