Skip to content

Conversation

@myoungwon
Copy link
Member

@myoungwon myoungwon commented May 23, 2025

Due to a recent change (adding shard_versions in object_info_t, 88ac6d9), the size of OI has increased. As a result, the OI can no longer be embedded directly in the onode, since its size now exceeds OI_MAX_LENGTH. This causes the OI data to be stored in the omap tree instead, leading to a performance drop in small random writes.

Signed-off-by: Myoungwon Oh ohmyoungwon@gmail.com

Contribution Guidelines

  • To sign and title your commits, please refer to Submitting Patches to Ceph.

  • If you are submitting a fix for a stable branch (e.g. "quincy"), please refer to Submitting Patches to Ceph - Backports for the proper workflow.

  • When filling out the below checklist, you may click boxes directly in the GitHub web UI. When entering or editing the entire PR message in the GitHub web UI editor, you may also select a checklist item by adding an x between the brackets: [x]. Spaces and capitalization matter when checking off items this way.

Checklist

  • Tracker (select at least one)
    • References tracker ticket
    • Very recent bug; references commit where it was introduced
    • New feature (ticket optional)
    • Doc update (no ticket needed)
    • Code cleanup (no ticket needed)
  • Component impact
    • Affects Dashboard, opened tracker ticket
    • Affects Orchestrator, opened tracker ticket
    • No impact that needs to be tracked
  • Documentation (select at least one)
    • Updates relevant documentation
    • No doc update is appropriate
  • Tests (select at least one)
Show available Jenkins commands

@myoungwon myoungwon requested a review from a team as a code owner May 23, 2025 14:04
@myoungwon
Copy link
Member Author

myoungwon commented May 23, 2025

@cyx1231st As we discussed in https://docs.google.com/document/d/1LX5nDX91kAAsEJD3BOfPv1o0F3HeMSwuJMXFNLl-QXw/edit?disco=AAABjKuGoMQ, I identified the root cause of performance degradation in terms of random write (RBM case), The first is related to seastore_max_data_allocation_size, which I’ve already shared and the second is addressed in this PR. With two fixes applied, I confirmed the number is slightly over around 3800 IOPS (the performance is recovered).

@myoungwon myoungwon closed this May 23, 2025
@myoungwon myoungwon reopened this May 23, 2025
…in the omap tree

Due to a recent change (adding shard_versions in object_info_t),
the size of OI has increased to 236. This causes to store OI data to the omap tree
because the size is over than OI_MAX_LENGTH. As a result, this results in
performance drop in small random write.

Signed-off-by: Myoungwon Oh <ohmyoungwon@gmail.com>
@myoungwon myoungwon force-pushed the wip-fix-oi-max-length branch from e074d13 to 135c035 Compare May 23, 2025 14:10
@cyx1231st
Copy link
Member

jenkins retest this please

@cyx1231st cyx1231st moved this from Needs QA to Tested in Crimson May 27, 2025
@cyx1231st cyx1231st merged commit bde3794 into ceph:main May 27, 2025
21 of 22 checks passed
@cyx1231st cyx1231st moved this from Tested to Tentacle Open Backports in Crimson May 27, 2025
@Matan-B Matan-B moved this from Tentacle Open Backports to Merged (Main) in Crimson May 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: Merged (Main)

Development

Successfully merging this pull request may close these issues.

2 participants