Somehow throotle recovery even further than basic options?
Hi, 4 years ago we've created our cluster with all disks 4osds (ssds and nvme disks) on octopus. The 15TB SSDs still working properly with 4 osds but the small 1.8T nvmes with the index pool not. Each new nvme osd adding to the existing nodes generates slow ops with scrub off, recovery_op_priority 1, backfill and recovery 1-1. I even turned off all index pool heavy sync mechanism but the read latency still high which means recovery op pushes it even higher. I'm trying to somehow add resource to the cluster to spread the 2048 index pool pg (in replica 3 means 6144pg index pool) but can't make it more gentle. The balancer is working in upmap with max deviation 1. Have this script from digitalocean https://github.com/digitalocean/pgremapper, is there anybody tried it before how is it or could this help actually? Thank you the ideas. ________________________________ This message is confidential and is for the sole use of the intended recipient(s). It may also be privileged or otherwise protected by copyright or other legal rules. If you have received it by mistake please let us know by reply email and delete it from your system. It is prohibited to copy this message or disclose its content to anyone. Any confidentiality or privilege is not waived or lost by any mistaken delivery or unauthorized disclosure of the message. All messages sent to and from Agoda may be monitored to ensure compliance with company policies, to protect the company's interests and to remove potential malware. Electronic messages may be intercepted, amended, lost or deleted, or contain viruses.
Forgot to paste, somehow I want to reduce this recovery operation: recovery: 0 B/s, 941.90k keys/s, 188 objects/s To 2-300Keys/sec ________________________________ From: Szabo, Istvan (Agoda) <Istvan.Szabo@agoda.com> Sent: Friday, September 6, 2024 11:18 PM To: Ceph Users <ceph-users@ceph.io> Subject: [ceph-users] Somehow throotle recovery even further than basic options? Hi, 4 years ago we've created our cluster with all disks 4osds (ssds and nvme disks) on octopus. The 15TB SSDs still working properly with 4 osds but the small 1.8T nvmes with the index pool not. Each new nvme osd adding to the existing nodes generates slow ops with scrub off, recovery_op_priority 1, backfill and recovery 1-1. I even turned off all index pool heavy sync mechanism but the read latency still high which means recovery op pushes it even higher. I'm trying to somehow add resource to the cluster to spread the 2048 index pool pg (in replica 3 means 6144pg index pool) but can't make it more gentle. The balancer is working in upmap with max deviation 1. Have this script from digitalocean https://github.com/digitalocean/pgremapper, is there anybody tried it before how is it or could this help actually? Thank you the ideas. ________________________________ This message is confidential and is for the sole use of the intended recipient(s). It may also be privileged or otherwise protected by copyright or other legal rules. If you have received it by mistake please let us know by reply email and delete it from your system. It is prohibited to copy this message or disclose its content to anyone. Any confidentiality or privilege is not waived or lost by any mistaken delivery or unauthorized disclosure of the message. All messages sent to and from Agoda may be monitored to ensure compliance with company policies, to protect the company's interests and to remove potential malware. Electronic messages may be intercepted, amended, lost or deleted, or contain viruses. _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
I can’t say anything about the pgremapper, but have you tried increasing the crush weight gradually? Add new OSDs with crush initial weight 0 and then increase it in small steps. I haven’t used that approach for years, but maybe that can help here. Or are all OSDs already up and in? Or you could reduce the max misplaced ratio to 1% or even lower (default is 5%)? Zitat von "Szabo, Istvan (Agoda)" <Istvan.Szabo@agoda.com>:
Forgot to paste, somehow I want to reduce this recovery operation: recovery: 0 B/s, 941.90k keys/s, 188 objects/s To 2-300Keys/sec
________________________________ From: Szabo, Istvan (Agoda) <Istvan.Szabo@agoda.com> Sent: Friday, September 6, 2024 11:18 PM To: Ceph Users <ceph-users@ceph.io> Subject: [ceph-users] Somehow throotle recovery even further than basic options?
Hi,
4 years ago we've created our cluster with all disks 4osds (ssds and nvme disks) on octopus. The 15TB SSDs still working properly with 4 osds but the small 1.8T nvmes with the index pool not. Each new nvme osd adding to the existing nodes generates slow ops with scrub off, recovery_op_priority 1, backfill and recovery 1-1. I even turned off all index pool heavy sync mechanism but the read latency still high which means recovery op pushes it even higher.
I'm trying to somehow add resource to the cluster to spread the 2048 index pool pg (in replica 3 means 6144pg index pool) but can't make it more gentle.
The balancer is working in upmap with max deviation 1.
Have this script from digitalocean https://github.com/digitalocean/pgremapper, is there anybody tried it before how is it or could this help actually?
Thank you the ideas.
________________________________ This message is confidential and is for the sole use of the intended recipient(s). It may also be privileged or otherwise protected by copyright or other legal rules. If you have received it by mistake please let us know by reply email and delete it from your system. It is prohibited to copy this message or disclose its content to anyone. Any confidentiality or privilege is not waived or lost by any mistaken delivery or unauthorized disclosure of the message. All messages sent to and from Agoda may be monitored to ensure compliance with company policies, to protect the company's interests and to remove potential malware. Electronic messages may be intercepted, amended, lost or deleted, or contain viruses. _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
This sounds interesting because this way the pressure wouldn't be too big if go like 0.1 0.2 OSD by OSD. What I can see how ceph did it, when add the new OSDs, the complete host get the remapped pgs from other hosts also, so the old osds PG number increased by like +50% (which was already overloaded) and slowly rebalance to the newly added osds on the same host. This initial pressure to big. This "misplaced ratio to 1%" I've never tried, let me read a bit, thank you. Istvan ________________________________ From: Eugen Block <eblock@nde.ag> Sent: Saturday, September 7, 2024 4:55:40 AM To: ceph-users@ceph.io <ceph-users@ceph.io> Subject: [ceph-users] Re: Somehow throotle recovery even further than basic options? Email received from the internet. If in doubt, don't click any link nor open any attachment ! ________________________________ I can’t say anything about the pgremapper, but have you tried increasing the crush weight gradually? Add new OSDs with crush initial weight 0 and then increase it in small steps. I haven’t used that approach for years, but maybe that can help here. Or are all OSDs already up and in? Or you could reduce the max misplaced ratio to 1% or even lower (default is 5%)? Zitat von "Szabo, Istvan (Agoda)" <Istvan.Szabo@agoda.com>:
Forgot to paste, somehow I want to reduce this recovery operation: recovery: 0 B/s, 941.90k keys/s, 188 objects/s To 2-300Keys/sec
________________________________ From: Szabo, Istvan (Agoda) <Istvan.Szabo@agoda.com> Sent: Friday, September 6, 2024 11:18 PM To: Ceph Users <ceph-users@ceph.io> Subject: [ceph-users] Somehow throotle recovery even further than basic options?
Hi,
4 years ago we've created our cluster with all disks 4osds (ssds and nvme disks) on octopus. The 15TB SSDs still working properly with 4 osds but the small 1.8T nvmes with the index pool not. Each new nvme osd adding to the existing nodes generates slow ops with scrub off, recovery_op_priority 1, backfill and recovery 1-1. I even turned off all index pool heavy sync mechanism but the read latency still high which means recovery op pushes it even higher.
I'm trying to somehow add resource to the cluster to spread the 2048 index pool pg (in replica 3 means 6144pg index pool) but can't make it more gentle.
The balancer is working in upmap with max deviation 1.
Have this script from digitalocean https://github.com/digitalocean/pgremapper, is there anybody tried it before how is it or could this help actually?
Thank you the ideas.
________________________________ This message is confidential and is for the sole use of the intended recipient(s). It may also be privileged or otherwise protected by copyright or other legal rules. If you have received it by mistake please let us know by reply email and delete it from your system. It is prohibited to copy this message or disclose its content to anyone. Any confidentiality or privilege is not waived or lost by any mistaken delivery or unauthorized disclosure of the message. All messages sent to and from Agoda may be monitored to ensure compliance with company policies, to protect the company's interests and to remove potential malware. Electronic messages may be intercepted, amended, lost or deleted, or contain viruses. _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io ________________________________ This message is confidential and is for the sole use of the intended recipient(s). It may also be privileged or otherwise protected by copyright or other legal rules. If you have received it by mistake please let us know by reply email and delete it from your system. It is prohibited to copy this message or disclose its content to anyone. Any confidentiality or privilege is not waived or lost by any mistaken delivery or unauthorized disclosure of the message. All messages sent to and from Agoda may be monitored to ensure compliance with company policies, to protect the company's interests and to remove potential malware. Electronic messages may be intercepted, amended, lost or deleted, or contain viruses.
This sounds interesting because this way the pressure wouldn't be too big if go like 0.1 0.2 OSD by OSD.
I used to do this as well, back before pg-upmap was a thing, and while I still had Jewel clients. It is however less efficient, because some data ends up moving more than once. Upweighting a handful of OSDs at the same time may spread the load and allow faster progress than going one at a time. Say one per host or one per failure domain. The PG remapping tools allow fine-grained control with more efficiency, though any clients that aren’t Luminous or later will have a really bad day.
What I can see how ceph did it, when add the new OSDs, the complete host get the remapped pgs from other hosts also, so the old osds PG number increased by like +50% (which was already overloaded) and slowly rebalance to the newly added osds on the same host. This initial pressure to big.
I don’t follow; adding new OSDs should on average decrease the PG replicas on the existing OSDs. But imbalances during topology changes are one reason I like to raise mon_max_pg_per_osd to 1000, otherwise you can end up with PGs that won’t activate.
This "misplaced ratio to 1%" I've never tried, let me read a bit, thank you.
Istvan ________________________________ From: Eugen Block <eblock@nde.ag> Sent: Saturday, September 7, 2024 4:55:40 AM To: ceph-users@ceph.io <ceph-users@ceph.io> Subject: [ceph-users] Re: Somehow throotle recovery even further than basic options?
Email received from the internet. If in doubt, don't click any link nor open any attachment ! ________________________________
I can’t say anything about the pgremapper, but have you tried increasing the crush weight gradually? Add new OSDs with crush initial weight 0 and then increase it in small steps. I haven’t used that approach for years, but maybe that can help here. Or are all OSDs already up and in? Or you could reduce the max misplaced ratio to 1% or even lower (default is 5%)?
Zitat von "Szabo, Istvan (Agoda)" <Istvan.Szabo@agoda.com>:
Forgot to paste, somehow I want to reduce this recovery operation: recovery: 0 B/s, 941.90k keys/s, 188 objects/s To 2-300Keys/sec
________________________________ From: Szabo, Istvan (Agoda) <Istvan.Szabo@agoda.com> Sent: Friday, September 6, 2024 11:18 PM To: Ceph Users <ceph-users@ceph.io> Subject: [ceph-users] Somehow throotle recovery even further than basic options?
Hi,
4 years ago we've created our cluster with all disks 4osds (ssds and nvme disks) on octopus. The 15TB SSDs still working properly with 4 osds but the small 1.8T nvmes with the index pool not. Each new nvme osd adding to the existing nodes generates slow ops with scrub off, recovery_op_priority 1, backfill and recovery 1-1. I even turned off all index pool heavy sync mechanism but the read latency still high which means recovery op pushes it even higher.
I'm trying to somehow add resource to the cluster to spread the 2048 index pool pg (in replica 3 means 6144pg index pool) but can't make it more gentle.
The balancer is working in upmap with max deviation 1.
Have this script from digitalocean https://github.com/digitalocean/pgremapper, is there anybody tried it before how is it or could this help actually?
Thank you the ideas.
________________________________ This message is confidential and is for the sole use of the intended recipient(s). It may also be privileged or otherwise protected by copyright or other legal rules. If you have received it by mistake please let us know by reply email and delete it from your system. It is prohibited to copy this message or disclose its content to anyone. Any confidentiality or privilege is not waived or lost by any mistaken delivery or unauthorized disclosure of the message. All messages sent to and from Agoda may be monitored to ensure compliance with company policies, to protect the company's interests and to remove potential malware. Electronic messages may be intercepted, amended, lost or deleted, or contain viruses. _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
________________________________ This message is confidential and is for the sole use of the intended recipient(s). It may also be privileged or otherwise protected by copyright or other legal rules. If you have received it by mistake please let us know by reply email and delete it from your system. It is prohibited to copy this message or disclose its content to anyone. Any confidentiality or privilege is not waived or lost by any mistaken delivery or unauthorized disclosure of the message. All messages sent to and from Agoda may be monitored to ensure compliance with company policies, to protect the company's interests and to remove potential malware. Electronic messages may be intercepted, amended, lost or deleted, or contain viruses. _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
* I don’t follow; adding new OSDs should on average decrease the PG replicas on the existing OSDs. But imbalances during topology changes are one reason I like to raise mon_max_pg_per_osd to 1000, otherwise you can end up with PGs that won’t activate. Yeah, have a look here: https://ibb.co/WVq3hNr This time the existing osd on the same host got a spike with other pgs which is not good 😕 after it slowly goes down. This is the node in the crush tree: -37 118.75211 host osd-2s12 440 nvme 0.43660 osd.440 up 1.00000 1.00000 441 nvme 0.43660 osd.441 up 1.00000 1.00000 442 nvme 0.43660 osd.442 up 1.00000 1.00000 443 nvme 0.43660 osd.443 up 1.00000 1.00000 444 nvme 0.43660 osd.444 up 1.00000 1.00000 445 nvme 0.43660 osd.445 up 1.00000 1.00000 446 nvme 0.43660 osd.446 up 1.00000 1.00000 447 nvme 0.43660 osd.447 up 1.00000 1.00000 596 nvme 1.74660 osd.596 up 0.50000 1.00000 597 nvme 1.74660 osd.597 up 0.50000 1.00000 440-447 are 2x 1.7TB nvmes with 4 osds on those. 596-597 is the newly added 3.8TB nvme disk with 2 osd to spread the pgs somehow on the node. I want to remove to be honest all the 4osd/nvme from the cluster and have only 1x osd on those 1.7TB nvmes but first I need space for the pgs so I think better to add first the nvmes rather than remove and reprovision. Or maybe I should reweight to 0 all of them and make a clear node without nvme, then add all the nvmes back to the node? Not sure extension or removal is the better option. ________________________________ From: Anthony D'Atri <anthony.datri@gmail.com> Sent: Saturday, September 7, 2024 9:35 AM To: Szabo, Istvan (Agoda) <Istvan.Szabo@agoda.com> Cc: Eugen Block <eblock@nde.ag>; ceph-users@ceph.io <ceph-users@ceph.io> Subject: Re: [ceph-users] Somehow throotle recovery even further than basic options? Email received from the internet. If in doubt, don't click any link nor open any attachment ! ________________________________
This sounds interesting because this way the pressure wouldn't be too big if go like 0.1 0.2 OSD by OSD.
I used to do this as well, back before pg-upmap was a thing, and while I still had Jewel clients. It is however less efficient, because some data ends up moving more than once. Upweighting a handful of OSDs at the same time may spread the load and allow faster progress than going one at a time. Say one per host or one per failure domain. The PG remapping tools allow fine-grained control with more efficiency, though any clients that aren’t Luminous or later will have a really bad day.
What I can see how ceph did it, when add the new OSDs, the complete host get the remapped pgs from other hosts also, so the old osds PG number increased by like +50% (which was already overloaded) and slowly rebalance to the newly added osds on the same host. This initial pressure to big.
I don’t follow; adding new OSDs should on average decrease the PG replicas on the existing OSDs. But imbalances during topology changes are one reason I like to raise mon_max_pg_per_osd to 1000, otherwise you can end up with PGs that won’t activate.
This "misplaced ratio to 1%" I've never tried, let me read a bit, thank you.
Istvan ________________________________ From: Eugen Block <eblock@nde.ag> Sent: Saturday, September 7, 2024 4:55:40 AM To: ceph-users@ceph.io <ceph-users@ceph.io> Subject: [ceph-users] Re: Somehow throotle recovery even further than basic options?
Email received from the internet. If in doubt, don't click any link nor open any attachment ! ________________________________
I can’t say anything about the pgremapper, but have you tried increasing the crush weight gradually? Add new OSDs with crush initial weight 0 and then increase it in small steps. I haven’t used that approach for years, but maybe that can help here. Or are all OSDs already up and in? Or you could reduce the max misplaced ratio to 1% or even lower (default is 5%)?
Zitat von "Szabo, Istvan (Agoda)" <Istvan.Szabo@agoda.com>:
Forgot to paste, somehow I want to reduce this recovery operation: recovery: 0 B/s, 941.90k keys/s, 188 objects/s To 2-300Keys/sec
________________________________ From: Szabo, Istvan (Agoda) <Istvan.Szabo@agoda.com> Sent: Friday, September 6, 2024 11:18 PM To: Ceph Users <ceph-users@ceph.io> Subject: [ceph-users] Somehow throotle recovery even further than basic options?
Hi,
4 years ago we've created our cluster with all disks 4osds (ssds and nvme disks) on octopus. The 15TB SSDs still working properly with 4 osds but the small 1.8T nvmes with the index pool not. Each new nvme osd adding to the existing nodes generates slow ops with scrub off, recovery_op_priority 1, backfill and recovery 1-1. I even turned off all index pool heavy sync mechanism but the read latency still high which means recovery op pushes it even higher.
I'm trying to somehow add resource to the cluster to spread the 2048 index pool pg (in replica 3 means 6144pg index pool) but can't make it more gentle.
The balancer is working in upmap with max deviation 1.
Have this script from digitalocean https://github.com/digitalocean/pgremapper, is there anybody tried it before how is it or could this help actually?
Thank you the ideas.
________________________________ This message is confidential and is for the sole use of the intended recipient(s). It may also be privileged or otherwise protected by copyright or other legal rules. If you have received it by mistake please let us know by reply email and delete it from your system. It is prohibited to copy this message or disclose its content to anyone. Any confidentiality or privilege is not waived or lost by any mistaken delivery or unauthorized disclosure of the message. All messages sent to and from Agoda may be monitored to ensure compliance with company policies, to protect the company's interests and to remove potential malware. Electronic messages may be intercepted, amended, lost or deleted, or contain viruses. _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
________________________________ This message is confidential and is for the sole use of the intended recipient(s). It may also be privileged or otherwise protected by copyright or other legal rules. If you have received it by mistake please let us know by reply email and delete it from your system. It is prohibited to copy this message or disclose its content to anyone. Any confidentiality or privilege is not waived or lost by any mistaken delivery or unauthorized disclosure of the message. All messages sent to and from Agoda may be monitored to ensure compliance with company policies, to protect the company's interests and to remove potential malware. Electronic messages may be intercepted, amended, lost or deleted, or contain viruses. _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
The pgremapper (and the python one) will allow you to mark all the PGs that a new disk gets as an empty-misplaced PG to be correct where they currently are. This means that after you run one of the remappers, the upmap will tell the cluster to stay as it is even though new empty OSDs have arrived with correct crush weights and all. So you set norebalance, add N+1 new OSDs, the cluster shudders for a short while when the new-empty PGs are created on the new drives, then you have lots and lots of misplaced PGs which norebalance prevents from starting backfills on. Then you run the remapper and "fix" the upmap so all the current placements are considered "correct", and hence the PGs that were supposed to move stop being misplaced. After this, you remove "norebalance" to allow moves to start happening. By now, no movement (or at least very few PGs) should occur. What happens next is that the balancer notices there actually is more space, and figures out the optimal result is more or less the same as above where lots of PGs should go to the new OSDs, but it does this with the max-misplaced-ratio in mind, and it will "move" the PGs by just unsetting their upmap entry that forced them to want to stay in place, so as time passes, it moves a few PGs at a time, and moves them by removing the upmaps from them so that most of the time your other OSDs will look perfectly healthy and will continue to do all the scrubs and things a healthy OSD should do and which it will not do if it has a long queue of backfills waiting to eat up all the slots for non-client IO. While you can do soft additions with increasing crush weights, this potentially causes lots of more movements since an OSD host with OSDs going from 0.1 to 0.2 weight might not place all PGs in the same spot in those two cases, so you could have movement within the host and so on from the recalculated pseudorandom placements on every increase. Den lör 7 sep. 2024 kl 00:15 skrev Eugen Block <eblock@nde.ag>:
I can’t say anything about the pgremapper, but have you tried increasing the crush weight gradually? Add new OSDs with crush initial weight 0 and then increase it in small steps. I haven’t used that approach for years, but maybe that can help here. Or are all OSDs already up and in? Or you could reduce the max misplaced ratio to 1% or even lower (default is 5%)?
Zitat von "Szabo, Istvan (Agoda)" <Istvan.Szabo@agoda.com>:
Forgot to paste, somehow I want to reduce this recovery operation: recovery: 0 B/s, 941.90k keys/s, 188 objects/s To 2-300Keys/sec
________________________________ From: Szabo, Istvan (Agoda) <Istvan.Szabo@agoda.com> Sent: Friday, September 6, 2024 11:18 PM To: Ceph Users <ceph-users@ceph.io> Subject: [ceph-users] Somehow throotle recovery even further than basic options?
Hi,
4 years ago we've created our cluster with all disks 4osds (ssds and nvme disks) on octopus. The 15TB SSDs still working properly with 4 osds but the small 1.8T nvmes with the index pool not. Each new nvme osd adding to the existing nodes generates slow ops with scrub off, recovery_op_priority 1, backfill and recovery 1-1. I even turned off all index pool heavy sync mechanism but the read latency still high which means recovery op pushes it even higher.
I'm trying to somehow add resource to the cluster to spread the 2048 index pool pg (in replica 3 means 6144pg index pool) but can't make it more gentle.
The balancer is working in upmap with max deviation 1.
Have this script from digitalocean https://github.com/digitalocean/pgremapper, is there anybody tried it before how is it or could this help actually?
Thank you the ideas.
________________________________ This message is confidential and is for the sole use of the intended recipient(s). It may also be privileged or otherwise protected by copyright or other legal rules. If you have received it by mistake please let us know by reply email and delete it from your system. It is prohibited to copy this message or disclose its content to anyone. Any confidentiality or privilege is not waived or lost by any mistaken delivery or unauthorized disclosure of the message. All messages sent to and from Agoda may be monitored to ensure compliance with company policies, to protect the company's interests and to remove potential malware. Electronic messages may be intercepted, amended, lost or deleted, or contain viruses. _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
-- May the most significant bit of your life be positive.
Hi, the presentation from Dan van der Ster should answer all your questions: https://youtu.be/9lsByOMdEwc?si=GfvICgZCnT2L93Tn If you have no time, start at 17:00 min. Joachim joachim.kraftmayer@clyso.com www.clyso.com Janne Johansson <icepic.dz@gmail.com> schrieb am Sa., 7. Sept. 2024, 09:00:
The pgremapper (and the python one) will allow you to mark all the PGs that a new disk gets as an empty-misplaced PG to be correct where they currently are. This means that after you run one of the remappers, the upmap will tell the cluster to stay as it is even though new empty OSDs have arrived with correct crush weights and all.
So you set norebalance, add N+1 new OSDs, the cluster shudders for a short while when the new-empty PGs are created on the new drives, then you have lots and lots of misplaced PGs which norebalance prevents from starting backfills on.
Then you run the remapper and "fix" the upmap so all the current placements are considered "correct", and hence the PGs that were supposed to move stop being misplaced. After this, you remove "norebalance" to allow moves to start happening.
By now, no movement (or at least very few PGs) should occur. What happens next is that the balancer notices there actually is more space, and figures out the optimal result is more or less the same as above where lots of PGs should go to the new OSDs, but it does this with the max-misplaced-ratio in mind, and it will "move" the PGs by just unsetting their upmap entry that forced them to want to stay in place, so as time passes, it moves a few PGs at a time, and moves them by removing the upmaps from them so that most of the time your other OSDs will look perfectly healthy and will continue to do all the scrubs and things a healthy OSD should do and which it will not do if it has a long queue of backfills waiting to eat up all the slots for non-client IO.
While you can do soft additions with increasing crush weights, this potentially causes lots of more movements since an OSD host with OSDs going from 0.1 to 0.2 weight might not place all PGs in the same spot in those two cases, so you could have movement within the host and so on from the recalculated pseudorandom placements on every increase.
Den lör 7 sep. 2024 kl 00:15 skrev Eugen Block <eblock@nde.ag>:
I can’t say anything about the pgremapper, but have you tried increasing the crush weight gradually? Add new OSDs with crush initial weight 0 and then increase it in small steps. I haven’t used that approach for years, but maybe that can help here. Or are all OSDs already up and in? Or you could reduce the max misplaced ratio to 1% or even lower (default is 5%)?
Zitat von "Szabo, Istvan (Agoda)" <Istvan.Szabo@agoda.com>:
Forgot to paste, somehow I want to reduce this recovery operation: recovery: 0 B/s, 941.90k keys/s, 188 objects/s To 2-300Keys/sec
________________________________ From: Szabo, Istvan (Agoda) <Istvan.Szabo@agoda.com> Sent: Friday, September 6, 2024 11:18 PM To: Ceph Users <ceph-users@ceph.io> Subject: [ceph-users] Somehow throotle recovery even further than basic options?
Hi,
4 years ago we've created our cluster with all disks 4osds (ssds and nvme disks) on octopus. The 15TB SSDs still working properly with 4 osds but the small 1.8T nvmes with the index pool not. Each new nvme osd adding to the existing nodes generates slow ops with scrub off, recovery_op_priority 1, backfill and recovery 1-1. I even turned off all index pool heavy sync mechanism but the read latency still high which means recovery op pushes it even higher.
I'm trying to somehow add resource to the cluster to spread the 2048 index pool pg (in replica 3 means 6144pg index pool) but can't make it more gentle.
The balancer is working in upmap with max deviation 1.
Have this script from digitalocean https://github.com/digitalocean/pgremapper, is there anybody tried it before how is it or could this help actually?
Thank you the ideas.
________________________________ This message is confidential and is for the sole use of the intended recipient(s). It may also be privileged or otherwise protected by copyright or other legal rules. If you have received it by mistake please let us know by reply email and delete it from your system. It is prohibited to copy this message or disclose its content to anyone. Any confidentiality or privilege is not waived or lost by any mistaken delivery or unauthorized disclosure of the message. All messages sent to and from Agoda may be monitored to ensure compliance with company policies, to protect the company's interests and to remove potential malware. Electronic messages may be intercepted, amended, lost or deleted, or contain viruses. _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
-- May the most significant bit of your life be positive. _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
participants (5)
-
Anthony D'Atri
-
Eugen Block
-
Janne Johansson
-
Joachim Kraftmayer
-
Szabo, Istvan (Agoda)