mclock and massive reads
Hello, We have a question about mClock scheduling reads on pacific (16.2.14 currently). When we do massive reads, from let's say machines we want to drain containing a lot of data on EC pools, we observe quite frequently slow ops on the source OSDs. Those slow ops affect the client services, talking directly rados. If we kill the OSD that causes slow ops, the recovery stays more or less at the same speed, but no more slow ops. And when we tweak mClock, if we limit on the OSDs that are the source, nothing that we can observe happens. However, if we limit on the target OSDs, the global speed slows down, and the slow ops disappear. So our question, is mClock taking into account the reads as well as the writes? Or are the reads calculate to be less expensive than the writes? Thanks, Luis Domingues Proton AG
Hi Luis,
So our question, is mClock taking into account the reads as well as the writes? Or are the reads calculate to be less expensive than the writes?
mClock treats both reads and writes equally. When you say "massive reads", do you mean a predominantly read workload? Also, the size of the reads is also factored in to arrive at the cost of the operation. In general, the cost of an I/O operation in mClock is proportional to its size. The higher the cost, the longer the operation stays in the queue. That being said, the implementation of mClock on pacific is experimental at best. I would recommend upgrading to either quincy or reef considering the significant improvements that were made both in terms of scheduling and usability. -Sridhar
Luis Domingues Proton AG On Thursday, 28 March 2024 at 10:10, Sridhar Seshasayee <sseshasa@redhat.com> wrote:
Hi Luis,
So our question, is mClock taking into account the reads as well as the writes? Or are the reads calculate to be less expensive than the writes?
mClock treats both reads and writes equally. When you say "massive reads", do you mean a predominantly read workload? Also, the size of the reads is also factored in to arrive at the cost of the operation. In general, the cost of an I/O operation in mClock is proportional to its size. The higher the cost, the longer the operation stays in the queue. That being said, the implementation of mClock on pacific is experimental at best. I would recommend upgrading to either quincy or reef considering the significant improvements that were made both in terms of scheduling and usability.
-Sridhar _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
When I say massive reads, is when we are draining a disk or a node. Outside of that particular use case, everything works quite well. We plan upgrading in a near future, so we will see.
participants (2)
-
Luis Domingues
-
Sridhar Seshasayee