Bug #40583
closed
Lower the default value of osd_deep_scrub_large_omap_object_key_threshold
Added by Neha Ojha almost 5 years ago.
Updated over 4 years ago.
Backport:
luminous,mimic,nautilus
Description
The current default of 2million k/v pairs is too high. Recovery takes too long
for bucket index objects with this much omap data in particular, which blocks
access to client buckets until it completes.
Lower the default for osd_deep_scrub_large_omap_object_key_threshold so such
objects can be detected before they become a problem
- Status changed from New to Fix Under Review
- Assignee set to Neha Ojha
- Pull request ID set to 28782
- Status changed from Fix Under Review to Pending Backport
- Copied to Backport #40653: luminous: Lower the default value of osd_deep_scrub_large_omap_object_key_threshold added
- Copied to Backport #40654: mimic: Lower the default value of osd_deep_scrub_large_omap_object_key_threshold added
- Copied to Backport #40655: nautilus: Lower the default value of osd_deep_scrub_large_omap_object_key_threshold added
- Status changed from Pending Backport to Resolved
While running with --resolve-parent, the script "backport-create-issue" noticed that all backports of this issue are in status "Resolved".
- Related to Bug #42515: fs: OpenFileTable object shards have too many k/v pairs added
I am taking the liberty to add a couple of recent mailing list threads here that highlight a potentially unintended consequence of this change, all related to the radosgw usage log, in the hope that it'll make it easier for people to make the connection:
Also available in: Atom
PDF