Project

General

Profile

Bug #43455

Too many rgw.none indexes slow down list operations

Added by Ilsoo Byun 7 months ago. Updated 5 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
-
% Done:

0%

Source:
Tags:
Backport:
mimic, nautilus
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature:

Description

I don't know why rgw.none indexes are created so much.
To my knowledge, rgw.none index is generated when cancelling a rgw transaction.
I just assume that multiple LC processes would try to delete the same object simultaneously.

Anyway, whatever the reason is, in this situation, a list operation takes too much time to complete.
Looking at the log, it seems like it's stuck in an infinite loop.
The same keys appear multiple times.

terminal.png View (290 KB) Ilsoo Byun, 01/03/2020 08:25 AM


Related issues

Copied to rgw - Backport #43658: mimic: Too many rgw.none indexes slow down list operations Resolved
Copied to rgw - Backport #43728: nautilus: Too many rgw.none indexes slow down list operations Resolved

History

#2 Updated by Casey Bodley 7 months ago

  • Assignee set to Eric Ivancich

#3 Updated by Eric Ivancich 7 months ago

  • Pull request ID set to 32513

#4 Updated by Eric Ivancich 7 months ago

  • Status changed from New to Fix Under Review

#5 Updated by Eric Ivancich 7 months ago

  • Status changed from Fix Under Review to Pending Backport
  • Backport set to mimic

#6 Updated by Nathan Cutler 7 months ago

  • Copied to Backport #43658: mimic: Too many rgw.none indexes slow down list operations added

#7 Updated by Nathan Cutler 7 months ago

  • Backport changed from mimic to mimic, nautilus

don't see any indication that this would not be backportable to nautilus as well (?)

#8 Updated by Nathan Cutler 7 months ago

  • Copied to Backport #43728: nautilus: Too many rgw.none indexes slow down list operations added

#9 Updated by Nathan Cutler 5 months ago

  • 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" or "Rejected".

Also available in: Atom PDF