[jira] [Resolved] (HDDS-15031) [Website v2][Troubleshooting]Slow datanode decommission

["Wei-Chiu Chuang (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HDDS-15031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wei-Chiu Chuang resolved HDDS-15031.
------------------------------------
    Resolution: Fixed

> [Website v2][Troubleshooting]Slow datanode decommission
> -------------------------------------------------------
>
>                 Key: HDDS-15031
>                 URL: https://issues.apache.org/jira/browse/HDDS-15031
>             Project: Apache Ozone
>          Issue Type: Sub-task
>            Reporter: Wei-Chiu Chuang
>            Assignee: YUNG_CHENG
>            Priority: Major
>              Labels: pull-request-available
>
> In certain scenarios, a datanode can take a long time to be ready for decommission.
> A datanode transitions from DECOMMISSIONING to DECOMMISSIONED state if all containers are sufficiently replicated. For a dense datanode, that means hours to even days depending on the cluster size and network speed.
> Execute command 'ozone admin datanode status decommission' to monitor the status of decommission. Use Grafana to check out decommission and replication related metrics.
> If it feels slow, a few configuration properties can be bumped up to speed up decommissioning. hdds.scm.replication.datanode.replication.limit in SCM limit for concurrent replication commands that the SCM will send to a single Datanode;  hdds.datanode.replication.outofservice.limit.factor sets the weight of decommissioning commands over other commands from SCM.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For additional commands, e-mail: issues-help@ozone.apache.org