Actions
Bug #58606
closedosd: osd_recovery_cost with mClockScheduler enabled doesn't reflect the size of the object being recovered leading to degraded recovery performance..
Status:
Resolved
Priority:
Normal
Assignee:
Category:
Performance/Resource Usage
Target version:
-
% Done:
0%
Source:
Backport:
quincy, reef
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(RADOS):
OSD
Pull request ID:
Tags (freeform):
Merge Commit:
Fixed In:
v18.0.0-3828-ga9d46ad6dd1
Released In:
v19.2.0~2398
Upkeep Timestamp:
2025-07-12T19:07:28+00:00
Description
Currently osd_recovery_cost is set to a static value equivalent to 20 MiB.
This cost is set regardless of the size of the object being recovered.
This results in the recovery items, regardless of object size, to remain
in the mClock queue for the same amount of time. This negatively impacts
the performance of recovery ops.
To resolve this, osd_recovery_cost must reflect the size of the object
being recovered before enqueuing the item into the mClock queue.
See related BZ for more details: https://bugzilla.redhat.com/show_bug.cgi?id=2163473
Updated by Sridhar Seshasayee about 3 years ago
- Subject changed from osd: osd_recovery_cost with mClockScheduler enabled must reflect the size of the object being recovered. to osd: osd_recovery_cost with mClockScheduler enabled doesn't reflect the size of the object being recovered leading to degraded recovery performance..
Updated by Sridhar Seshasayee about 3 years ago
- Status changed from New to Fix Under Review
- Pull request ID set to 49975
Updated by Sridhar Seshasayee over 2 years ago
- Status changed from Fix Under Review to Pending Backport
Updated by Upkeep Bot over 2 years ago
- Copied to Backport #62129: quincy: osd: osd_recovery_cost with mClockScheduler enabled doesn't reflect the size of the object being recovered leading to degraded recovery performance.. added
Updated by Upkeep Bot over 2 years ago
- Copied to Backport #62130: reef: osd: osd_recovery_cost with mClockScheduler enabled doesn't reflect the size of the object being recovered leading to degraded recovery performance.. added
Updated by Sridhar Seshasayee over 2 years ago
- Status changed from Pending Backport to Resolved
Updated by Upkeep Bot 8 months ago
- Merge Commit set to a9d46ad6dd12efb51ffa29ef12be6b19761a0911
- Fixed In set to v18.0.0-3828-ga9d46ad6dd1
- Released In set to v19.2.0~2398
- Upkeep Timestamp set to 2025-07-12T19:07:28+00:00
Actions