Confusion re. obj-size-hist-max

Operations Configuration
1

Hi! We have objects in our ns which are larger than the default represented object size visible using the objsz histogram. As such, we would like to adjust the obj-size-hist-max upwards to increase visibility which as far as my interpretation of the documentation goes is a namespace context config parameter.

-To begin with, the objsz histogram currently returns 100 buckets - as the documented default. -Interrogating the namespace config using asinfo/asadm reveals no such config parameter. -Issuing an asinfo command to set the parameter at, for example, 100 results in an “ok” from asinfo. -Running a new objsz histogram post change (and “OK”) reveals a histogram still bound to 100 buckets.

Perhaps we are misinterpreting things here, feedback much appreciated. Tom

2

Tom, Histograms always return 100 buckets. For objsz histogram, the number after 100 represents the size of each bucket in read block size which is 128 bytes.

For example, you will see output like: 100,1,0,0,30,0… Means, there are 100 buckets, of size 1 ie (1 x 128 bytes) wide, bucket 0 always has zero records - obviously, bucket 1 here has zero records, bucket 2 has 30 records. Bucket 2 implies records of size between 129 and 256 bytes. (2 x 128 bytes uppper limit).

The size = 1 (or 128 bytes) is obj-size-hist-max divided by 100. obj-size-hist-max is 100 by default. You can set obj-size-hist-max to 1000. Then 1000/100 = 10. Your histogram should print like: 100,10,0,… . I have not tested that, but thats what you should get. Then each bucket is 10x128 bytes wide. Start counting buckets till the bucket where you see >zero records, starting with bucket zero. nth bucket has 55 records, then nX1280 bytes is the approximate size of those 55 records.

When you do change obj-size-hist-max, what does your output look like? Also, what is your data storage engine for this namespace? Trust it is SSD?

3

Hi - thanks for the reply!

Yes of course, bad formulation of the scenario re. no.buckets. I was of course referring to the size of each bucket. An example of the behaviour we are seeing (on re separate clusters running Community Edition 3.9.1)

[nosql ~]# asinfo -v “set-config:context=namespace;id=namespace;obj-size-hist-max=100” ok

[nosql ~]# asinfo -v “hist-dump:ns=namespace;set=ourSet;hist=objsz” namespace:objsz=100,1,0,146340,9858766,661706158,356421068,70460602,39488554,32275604,32199957,11953013,6097935,4096001,3149467,2283234,1576467,1214199,970682,788656,647686,537745,449799,380105,323367,276506,239948,209114,183585,161156,143821,127278,113596,101785,90968,81065,71236,61704,53160,45433,38143,31949,26510,21958,18280,15212,12743,10839,8960,7740,6553,5639,4804,4009,3436,2923,2454,2072,1679,1410,1101,883,725,636,409,273,139,77,35,5,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0;

[nosql ~]# asinfo -v “set-config:context=namespace;id=namespace;obj-size-hist-max=1000” ok

[nosql ~]# asinfo -v “hist-dump:ns=namespace;set=ourSet;hist=objsz” namespace:objsz=100,1,0,146340,9858766,661706158,356421068,70460602,39488554,32275604,32199957,11953013,6097935,4096001,3149467,2283234,1576467,1214199,970682,788656,647686,537745,449799,380105,323367,276506,239948,209114,183585,161156,143821,127278,113596,101785,90968,81065,71236,61704,53160,45433,38143,31949,26510,21958,18280,15212,12743,10839,8960,7740,6553,5639,4804,4009,3436,2923,2454,2072,1679,1410,1101,883,725,636,409,273,139,77,35,5,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0;

[nosql ~]# asinfo -v “set-config:context=namespace;id=namespace;obj-size-hist-max=200” ok

[nosql ~]# asinfo -v “hist-dump:ns=namespace;set=ourSet;hist=objsz” namespace:objsz=100,1,0,146340,9858766,661706158,356421068,70460602,39488554,32275604,32199957,11953013,6097935,4096001,3149467,2283234,1576467,1214199,970682,788656,647686,537745,449799,380105,323367,276506,239948,209114,183585,161156,143821,127278,113596,101785,90968,81065,71236,61704,53160,45433,38143,31949,26510,21958,18280,15212,12743,10839,8960,7740,6553,5639,4804,4009,3436,2923,2454,2072,1679,1410,1101,883,725,636,409,273,139,77,35,5,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0;

Also, irrespective of the issue with us apparently being unable to change this value - should the config not be visible when interrogating the runtime configuration? Or is the intention that the 2nd digit of the objsz hist output is the only place to see it (*100)?

Thanks Tom

4

I see that CE Release Notes for ver 3.10.1 acknowledge a bug fix regarding the configuration issue you raise in the last para. AER-5379 on obj-size-hist-max. Can you test the histogram issue with 3.10.1 or higher? You can use the Java Benchmark tool to insert data. Also, histograms are computed by nsup thread. Make sure nsup thread has had a chance to run after you change the parameter. Check in the logs - grep thr_nsup and see the time its taking to run and what its period is (default config is every 2 min).

5

I tested with CE 3.9.1. Here are the results: I had 300,000 records, each 2048 byte string, single bin. (Bucket 17, when width =1 or 128 bytes)

$ asinfo -v 'hist-dump:ns=ns1;hist=objsz'
ns1:objsz=100,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,300000,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0;
$ asinfo -v 'set-config:context=service;nsup-period=10'
ok
$ asinfo -v 'set-config:context=namespace;id=ns1;obj-size-hist-max=1000'
ok

Before nsup had a chance to run:

$ asinfo -v 'hist-dump:ns=ns1;hist=objsz'
ns1:objsz=100,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,300000,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0;

Wait ten seconds, let nsup run:

$ asinfo -v 'hist-dump:ns=ns1;hist=objsz'
ns1:objsz=100,10,0,300000,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0;