# TiKV nodes are slow to go offline (B)


![left](./student-guide/diagram/25-TiKV-solution-01-01.png)

------------------------------------------------------------
In this scenario, we start with Operator-related metrics to analyze the generation execution of the Operator. The related monitoring is as follows:
  - Grafana PD —> Operator —> Schedule Operator Create：The creation of the Operator
  - Grafana PD —> Operator —> Operator finish duration：Operator execution time consuming
  - Grafana PD —> Operator —> Operator Step duration：When it takes time to execute different Operator Steps
- If the schedule is generating normally, it's just slow
  - Scheduling speed is limited by the limit configuration. The limit parameter corresponding to the offline line is replica-schedule-limit, which can be adjusted appropriately. Similar to Balance, the max-pending-peer-count and max-snapshot-count limits can also be relaxed.
  - There is competition for other scheduling tasks running in the system at the same time, or the scheduling is running too slowly. The process method already been covered in the previous section and will not be discussed in detail.
  - When a single node is offline, the offline speed will be limited by the speed at which a single snapshot is generated because a large portion of the leaders in the region to be operated (about 1/3 in the 3 replica configuration) are concentrated on the offline nodes. You can speed it up by manually adding an evict-leader to this node to schedule the removal of the leader.
- If no corresponding Operator schedule is generated
  - Offline scheduling is turned off, or replica-schedule-limit is set to 0.
  - Unable to find a node to move the region. For example, if the capacity of alternative nodes with the same label is greater than 80% (parameter low-space-ratio), PD will stop scheduling to avoid the risk of bursting. This situation requires adding more nodes or removing some data to free up space.