Hi Eugen, There was a PR (https://github.com/ceph/ceph/pull/55040) related to mClock and snaptrim that was backported and available from v18.2.4. The fix more accurately determines the cost (instead of priority with wpq) of snaptrim operation depending on the average size of the objects in the PG. Depending on the active mClock profile, this should help move the snaptrim queue. To prevent the cluster getting into a similar situation again is to try and change the config osd_snap_trim_cost (I think it's set to 1 MiB by default) to a value that more accurately reflects the average object size of the PGs undergoing snaptrim and see if it helps. In general with mClock, lower cost ops spend less time in the queue. -Sridhar _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |