Re: The snaptrim queue of PGs has not decreased for several days.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Oh yeah, I think I stumbled upon that as well, but then it slipped my mind again. Thanks for pointing that out, I appreciate it!


Zitat von Sridhar Seshasayee <sseshasa@xxxxxxxxxx>:

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



[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux