]> git.apps.os.sepia.ceph.com Git - ceph-ci.git/commit
options/rgw: raise default rgw_max_listing_results=5000
authorCasey Bodley <cbodley@redhat.com>
Fri, 30 Aug 2024 14:07:37 +0000 (10:07 -0400)
committerCasey Bodley <cbodley@redhat.com>
Fri, 30 Aug 2024 14:07:39 +0000 (10:07 -0400)
commit789b5f352c5520a3803441e25358859dd4d52690
tree3e838c89ea9b257f3d9ee02dbc5361152ad0eb42
parent4b29809a1633499b7b315098a49df1958ba57bc9
options/rgw: raise default rgw_max_listing_results=5000

allow clients to request more than the default 1000 keys per request

bucket listing of large buckets (with many shards) can be more efficient
with larger batches. raising max-keys also improves the balls-into-bins
algorithm which we artificially cap at a minimum of 8 keys per shard

with the default max-keys=1000, we reach this min=8 at around 350
shards. above that shard count, we're always requesting more than the
optimal number of entries per shard, so wasting i/o and bandwidth

as we raise the max-keys, we push this minimum to higher shard
counts:

| max-keys | shard count |
|----------|-------------|
|     1000 |         350 |
|     2000 |         720 |
|     3000 |        1100 |
|     4000 |        1500 |
|     5000 |        1900 |

this table was calculated with the formula (using various values of max-keys):

> solve 8 = 1 + (1000/x + sqrt(2 * 1000 * log10(1000) / x))

ex. https://www.wolframalpha.com/input?i=solve+8+%3D+1+%2B+%281000%2Fx+%2B+sqrt%282+*+1000+*+log10%281000%29+%2F+x%29%29

raising max-keys does increase the total memory usage of each bucket
listing request, which gets into megabytes (tens to hundreds?). so i
chose 5000 as a cutoff that covers most of the range up to our current
rgw_max_dynamic_shards=1999

Signed-off-by: Casey Bodley <cbodley@redhat.com>
src/common/options/rgw.yaml.in