Great question @Srikanth_Reddy ! The short answer is, there is no easy way. This makes me sad.
-
You can continue to use objsz hist dump but its a rough estimate… Disk usage per set the first step is to increase your objsz until the last number in the dump is not 0. Each time you increase the objsz it can take a full nsup cycle for the next dump to reflect this (2-5 minutes for me…) . You don’t want to increase it too fast though, because if you overshoot it too much the ‘resolution’ will be lower - meaning it will be a rougher estimate. You can be sure your objsz change has taken effect by checking the second number in the dump and seeing that it has increased (this second number is the number of rblocks your objsz is set to). After you’ve gone through the process of getting the last number to 0, with the smallest objsz possible, then you can use the objsz output as an estimate. The larger your objsz, the less accurate the estimate. Once you have this data all set, you take the second number (your rblock size) and multiply it by 128 bytes. Then, you can look at your buckets using this number you just calculated from the rblocksizes as the BUCKET_WIDTH. BUCKET_0 are records between 0 * BUCKET_WIDTH and 1 * BUCKET_WIDTH. BUCKET_1 are records between 1 * BUCKET_WIDTH and 2 * BUCKET_WIDTH. a simple bash loop should work for this… Change width to what your calculated bucket_width and… width=128;count=0; sz=0; for i in {THE OBJSZ OUTPUT AFTER REMOVING THE FIRST 2 NUMBERS}; do count=((count+1)); sz=(($sz+($i*$count*$width)));done (or something similar)
-
You can setup a VM box or some test/lower environment, and backup the data from the environment you wish to measure and restore it into this empty environment. Namespace level stats can give you the details.
-
I have heard rumors these Aerospike guys have a tool for estimating non-LDT sets… Maybe its out there somewhere… @vshield?