From b990df05a90b59b84e57f06589faf5919191241d Mon Sep 17 00:00:00 2001 From: lhy1024 <19542290+lhy1024@users.noreply.github.com> Date: Wed, 24 Jun 2026 23:52:30 +0800 Subject: [PATCH 1/9] pd: document CPU-aware hot region scheduling --- grafana-pd-dashboard.md | 1 + pd-control.md | 27 +++++++++++++++++++++------ troubleshoot-hot-spot-issues.md | 4 ++++ 3 files changed, 26 insertions(+), 6 deletions(-) diff --git a/grafana-pd-dashboard.md b/grafana-pd-dashboard.md index 048dc0c7b3d69..224f3907a7ae0 100644 --- a/grafana-pd-dashboard.md +++ b/grafana-pd-dashboard.md @@ -89,6 +89,7 @@ The following is the description of PD Dashboard metrics items: - Total read bytes on hot peer Regions: The total read bytes of peers that have become read hotspots on each TiKV instance - Store read rate bytes: The total read bytes of each TiKV instance - Store read rate keys: The total read keys of each TiKV instance +- Store read cpu: The read CPU usage of each TiKV instance, which PD uses for CPU-aware read hotspot scheduling starting from v8.5.7 - Hot cache read entry number: The number of peers that are in the read hotspot statistics module on each TiKV instance ![PD Dashboard - Hot read metrics](/media/pd-dashboard-hotread-v4.png) diff --git a/pd-control.md b/pd-control.md index 2ecea97496f88..08942d9656f29 100644 --- a/pd-control.md +++ b/pd-control.md @@ -515,6 +515,7 @@ Usage: "hot_region_type": "read", "hot_degree": 152, "flow_bytes": 0, + "flow_cpu": 32, "key_rate": 0, "query_rate": 305, "start_key": "7480000000000000FF5300000000000000F8", @@ -536,6 +537,7 @@ Usage: "hot_region_type": "read", "hot_degree": 152, "flow_bytes": 0, + "flow_cpu": 32, "key_rate": 0, "query_rate": 305, "start_key": "7480000000000000FF5300000000000000F8", @@ -546,6 +548,8 @@ Usage: } ``` +Starting from v8.5.7, `hot read` and `hot history` include `flow_cpu`, and `hot store` includes `cpu-read-rate`. These fields show read CPU usage for CPU-aware read hotspot scheduling. + ### `label [store ]` Use this command to view the label information of the cluster. @@ -1025,22 +1029,24 @@ Usage: "min-hot-byte-rate": 100, "min-hot-key-rate": 10, "min-hot-query-rate": 10, + "min-hot-cpu-rate": 10, "max-zombie-rounds": 3, "max-peer-number": 1000, "byte-rate-rank-step-ratio": 0.05, "key-rate-rank-step-ratio": 0.05, "query-rate-rank-step-ratio": 0.05, + "cpu-rate-rank-step-ratio": 0.05, "count-rank-step-ratio": 0.01, "great-dec-ratio": 0.95, "minor-dec-ratio": 0.99, "src-tolerance-ratio": 1.05, "dst-tolerance-ratio": 1.05, "read-priorities": [ - "query", + "cpu", "byte" ], "write-leader-priorities": [ - "key", + "query", "byte" ], "write-peer-priorities": [ @@ -1071,6 +1077,12 @@ Usage: scheduler config balance-hot-region-scheduler set min-hot-query-rate 10 ``` +- `min-hot-cpu-rate` means the smallest CPU usage of read requests to be counted, which is usually 10. + + ```bash + scheduler config balance-hot-region-scheduler set min-hot-cpu-rate 10 + ``` + - `max-zombie-rounds` means the maximum number of heartbeats with which an operator can be considered as the pending influence. If you set it to a larger value, more operators might be included in the pending influence. Usually, you do not need to adjust its value. Pending influence refers to the operator influence that is generated during scheduling but still has an effect. ```bash @@ -1083,7 +1095,7 @@ Usage: scheduler config balance-hot-region-scheduler set max-peer-number 1000 ``` -- `byte-rate-rank-step-ratio`, `key-rate-rank-step-ratio`, `query-rate-rank-step-ratio`, and `count-rank-step-ratio` respectively mean the step ranks of byte, key, query, and count. The rank-step-ratio decides the step when the rank is calculated. `great-dec-ratio` and `minor-dec-ratio` are used to determine the `dec` rank. Usually, you do not need to modify these items. +- `byte-rate-rank-step-ratio`, `key-rate-rank-step-ratio`, `query-rate-rank-step-ratio`, `cpu-rate-rank-step-ratio`, and `count-rank-step-ratio` respectively mean the step ranks of byte, key, query, CPU, and count. The rank-step-ratio decides the step when the rank is calculated. `great-dec-ratio` and `minor-dec-ratio` are used to determine the `dec` rank. Usually, you do not need to modify these items. ```bash scheduler config balance-hot-region-scheduler set byte-rate-rank-step-ratio 0.05 @@ -1097,15 +1109,18 @@ Usage: - `read-priorities`, `write-leader-priorities`, and `write-peer-priorities` control which dimension the scheduler prioritizes for hot Region scheduling. Two dimensions are supported for configuration. - - `read-priorities` and `write-leader-priorities` control which dimensions the scheduler prioritizes for scheduling hot Regions of the read and write-leader types. The dimension options are `query`, `byte`, and `key`. + - `read-priorities` controls which dimensions the scheduler prioritizes for scheduling hot Regions of the read type. The dimension options are `cpu`, `query`, `byte`, and `key`. + - `write-leader-priorities` controls which dimensions the scheduler prioritizes for scheduling hot Regions of the write-leader type. The dimension options are `query`, `byte`, and `key`. - `write-peer-priorities` controls which dimensions the scheduler prioritizes for scheduling hot Regions of the write-peer type. The dimension options are `byte` and `key`. > **Note:** > - > If a cluster component is earlier than v5.2, the configuration of `query` dimension does not take effect. If some components are upgraded to v5.2 or later, the `byte` and `key` dimensions still by default have the priority for hot Region scheduling. After all components of the cluster are upgraded to v5.2 or later, such a configuration still takes effect for compatibility. You can view the real-time configuration using the `pd-ctl` command. Usually, you do not need to modify these configurations. + > If a cluster component is earlier than v5.2, the configuration of the `query` dimension does not take effect. If some components are upgraded to v5.2 or later, the `byte` and `key` dimensions still by default have the priority for hot Region scheduling. After all components of the cluster are upgraded to v5.2 or later, such a configuration still takes effect for compatibility. + > + > Starting from v8.5.7, TiKV reports read CPU usage for hot Region scheduling. For clusters that support read CPU reporting, the default `read-priorities` value is `cpu,byte`. For clusters that do not support read CPU reporting, PD automatically falls back to `query,byte`, or to `byte,key` if the `query` dimension is also unsupported. You can view the real-time configuration using the `pd-ctl` command. Usually, you do not need to modify these configurations. ```bash - scheduler config balance-hot-region-scheduler set read-priorities query,byte + scheduler config balance-hot-region-scheduler set read-priorities cpu,byte ``` - `strict-picking-store` controls the search space of hot Region scheduling. Usually, it is enabled. This configuration item only affects the behavior when `rank-formula-version` is `v1`. When it is enabled, hot Region scheduling ensures hot Region balance on the two configured dimensions. When it is disabled, hot Region scheduling only ensures the balance on the dimension with the first priority, which might reduce balance on other dimensions. Usually, you do not need to modify this configuration. diff --git a/troubleshoot-hot-spot-issues.md b/troubleshoot-hot-spot-issues.md index 5f1cbd369f40f..716e0651db27d 100644 --- a/troubleshoot-hot-spot-issues.md +++ b/troubleshoot-hot-spot-issues.md @@ -185,6 +185,10 @@ For more details, see [Coprocessor Cache](/coprocessor-cache.md). In a read hotspot scenario, the hotspot TiKV node cannot process read requests in time, resulting in the read requests queuing. However, not all TiKV resources are exhausted at this time. To reduce latency, TiDB v7.1.0 introduces the load-based replica read feature, which allows TiDB to read data from other TiKV nodes without queuing on the hotspot TiKV node. You can control the queue length of read requests using the [`tidb_load_based_replica_read_threshold`](/system-variables.md#tidb_load_based_replica_read_threshold-new-in-v700) system variable. When the estimated queue time of the leader node exceeds this threshold, TiDB prioritizes reading data from follower nodes. This feature can improve read throughput by 70% to 200% in a read hotspot scenario compared to not scattering read hotspots. +Starting from v8.5.7, PD supports CPU-aware Hot Region scheduling for read hotspots. TiKV reports per-Region read CPU usage in store heartbeats, and PD can use CPU usage as a scheduling dimension. This helps PD identify read hotspots whose QPS or byte throughput looks balanced but whose TiKV CPU usage is still uneven, such as workloads that contain queries with different CPU costs or clusters that contain TiKV nodes with different performance profiles. + +For clusters whose TiKV version supports read CPU reporting, the default `read-priorities` value of `balance-hot-region-scheduler` is `cpu,byte`. For clusters that do not support read CPU reporting, PD automatically falls back to `query,byte`, or to `byte,key` if the `query` dimension is also unsupported. To view or adjust the scheduling dimensions, use [`pd-ctl scheduler config balance-hot-region-scheduler`](/pd-control.md#scheduler-config-balance-hot-region-scheduler). + ## Use TiKV MVCC in-memory engine to mitigate read hotspots caused by high MVCC read amplification When the retention time of historical MVCC data for GC is too long, or when the records are frequently updated or deleted, read hotspots might occur due to scanning a large number of MVCC versions. To alleviate this type of hotspot, you can enable the [TiKV MVCC In-Memory Engine](/tikv-in-memory-engine.md) feature. From 98a618f1a3787c7a75f2262b1a3260104d41f695 Mon Sep 17 00:00:00 2001 From: lhy1024 <19542290+lhy1024@users.noreply.github.com> Date: Wed, 24 Jun 2026 23:57:31 +0800 Subject: [PATCH 2/9] pd: address CPU-aware scheduling doc comments --- grafana-pd-dashboard.md | 2 +- pd-control.md | 8 ++++---- troubleshoot-hot-spot-issues.md | 4 ++-- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/grafana-pd-dashboard.md b/grafana-pd-dashboard.md index 224f3907a7ae0..c3501b4d15ac4 100644 --- a/grafana-pd-dashboard.md +++ b/grafana-pd-dashboard.md @@ -89,7 +89,7 @@ The following is the description of PD Dashboard metrics items: - Total read bytes on hot peer Regions: The total read bytes of peers that have become read hotspots on each TiKV instance - Store read rate bytes: The total read bytes of each TiKV instance - Store read rate keys: The total read keys of each TiKV instance -- Store read cpu: The read CPU usage of each TiKV instance, which PD uses for CPU-aware read hotspot scheduling starting from v8.5.7 +- Store read cpu: The read CPU usage of each TiKV instance. PD uses this metric for CPU-aware read hotspot scheduling starting from v8.5.7. - Hot cache read entry number: The number of peers that are in the read hotspot statistics module on each TiKV instance ![PD Dashboard - Hot read metrics](/media/pd-dashboard-hotread-v4.png) diff --git a/pd-control.md b/pd-control.md index 08942d9656f29..28fa218f5091d 100644 --- a/pd-control.md +++ b/pd-control.md @@ -548,7 +548,7 @@ Usage: } ``` -Starting from v8.5.7, `hot read` and `hot history` include `flow_cpu`, and `hot store` includes `cpu-read-rate`. These fields show read CPU usage for CPU-aware read hotspot scheduling. +Starting from v8.5.7, the `hot read` and `hot history` commands include `flow_cpu`, and the `hot store` command includes `cpu-read-rate`. These fields show the read CPU usage for CPU-aware read hotspot scheduling. ### `label [store ]` @@ -1077,7 +1077,7 @@ Usage: scheduler config balance-hot-region-scheduler set min-hot-query-rate 10 ``` -- `min-hot-cpu-rate` means the smallest CPU usage of read requests to be counted, which is usually 10. +- `min-hot-cpu-rate` specifies the minimum CPU usage of read requests to count, which is usually 10. ```bash scheduler config balance-hot-region-scheduler set min-hot-cpu-rate 10 @@ -1095,7 +1095,7 @@ Usage: scheduler config balance-hot-region-scheduler set max-peer-number 1000 ``` -- `byte-rate-rank-step-ratio`, `key-rate-rank-step-ratio`, `query-rate-rank-step-ratio`, `cpu-rate-rank-step-ratio`, and `count-rank-step-ratio` respectively mean the step ranks of byte, key, query, CPU, and count. The rank-step-ratio decides the step when the rank is calculated. `great-dec-ratio` and `minor-dec-ratio` are used to determine the `dec` rank. Usually, you do not need to modify these items. +- `byte-rate-rank-step-ratio`, `key-rate-rank-step-ratio`, `query-rate-rank-step-ratio`, `cpu-rate-rank-step-ratio`, and `count-rank-step-ratio` represent the step ranks of byte, key, query, CPU, and count, respectively. The rank-step-ratio decides the step when calculating the rank. PD uses `great-dec-ratio` and `minor-dec-ratio` to determine the `dec` rank. Usually, you do not need to modify these items. ```bash scheduler config balance-hot-region-scheduler set byte-rate-rank-step-ratio 0.05 @@ -1117,7 +1117,7 @@ Usage: > > If a cluster component is earlier than v5.2, the configuration of the `query` dimension does not take effect. If some components are upgraded to v5.2 or later, the `byte` and `key` dimensions still by default have the priority for hot Region scheduling. After all components of the cluster are upgraded to v5.2 or later, such a configuration still takes effect for compatibility. > - > Starting from v8.5.7, TiKV reports read CPU usage for hot Region scheduling. For clusters that support read CPU reporting, the default `read-priorities` value is `cpu,byte`. For clusters that do not support read CPU reporting, PD automatically falls back to `query,byte`, or to `byte,key` if the `query` dimension is also unsupported. You can view the real-time configuration using the `pd-ctl` command. Usually, you do not need to modify these configurations. + > Starting from v8.5.7, TiKV reports read CPU usage for hot Region scheduling. For clusters that support read CPU reporting, the default `read-priorities` value is `cpu,byte`. For clusters that do not support read CPU reporting, PD automatically falls back to `query,byte`, or to `byte,key` if the cluster does not support the `query` dimension either. You can view the real-time configuration using the `pd-ctl` command. Usually, you do not need to modify these configurations. ```bash scheduler config balance-hot-region-scheduler set read-priorities cpu,byte diff --git a/troubleshoot-hot-spot-issues.md b/troubleshoot-hot-spot-issues.md index 716e0651db27d..44f4325970106 100644 --- a/troubleshoot-hot-spot-issues.md +++ b/troubleshoot-hot-spot-issues.md @@ -185,9 +185,9 @@ For more details, see [Coprocessor Cache](/coprocessor-cache.md). In a read hotspot scenario, the hotspot TiKV node cannot process read requests in time, resulting in the read requests queuing. However, not all TiKV resources are exhausted at this time. To reduce latency, TiDB v7.1.0 introduces the load-based replica read feature, which allows TiDB to read data from other TiKV nodes without queuing on the hotspot TiKV node. You can control the queue length of read requests using the [`tidb_load_based_replica_read_threshold`](/system-variables.md#tidb_load_based_replica_read_threshold-new-in-v700) system variable. When the estimated queue time of the leader node exceeds this threshold, TiDB prioritizes reading data from follower nodes. This feature can improve read throughput by 70% to 200% in a read hotspot scenario compared to not scattering read hotspots. -Starting from v8.5.7, PD supports CPU-aware Hot Region scheduling for read hotspots. TiKV reports per-Region read CPU usage in store heartbeats, and PD can use CPU usage as a scheduling dimension. This helps PD identify read hotspots whose QPS or byte throughput looks balanced but whose TiKV CPU usage is still uneven, such as workloads that contain queries with different CPU costs or clusters that contain TiKV nodes with different performance profiles. +Starting from v8.5.7, PD supports CPU-aware Hot Region scheduling for read hotspots. TiKV reports per-Region read CPU usage in store heartbeats, and PD can use CPU usage as a scheduling dimension. This helps PD identify read hotspots whose QPS or byte throughput looks balanced but whose TiKV CPU usage is still uneven, such as workloads with different CPU-cost queries or clusters with different TiKV performance profiles. -For clusters whose TiKV version supports read CPU reporting, the default `read-priorities` value of `balance-hot-region-scheduler` is `cpu,byte`. For clusters that do not support read CPU reporting, PD automatically falls back to `query,byte`, or to `byte,key` if the `query` dimension is also unsupported. To view or adjust the scheduling dimensions, use [`pd-ctl scheduler config balance-hot-region-scheduler`](/pd-control.md#scheduler-config-balance-hot-region-scheduler). +For clusters that support read CPU reporting, the default `read-priorities` value of `balance-hot-region-scheduler` is `cpu,byte`. For clusters that do not support read CPU reporting, PD automatically falls back to `query,byte`, or to `byte,key` if the cluster does not support the `query` dimension either. To view or adjust the scheduling dimensions, use [`pd-ctl scheduler config balance-hot-region-scheduler`](/pd-control.md#scheduler-config-balance-hot-region-scheduler). ## Use TiKV MVCC in-memory engine to mitigate read hotspots caused by high MVCC read amplification From 08b1104aa458964809d9a1847ca5285445b37ff6 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Thu, 2 Jul 2026 13:31:48 +0800 Subject: [PATCH 3/9] Apply suggestions from code review --- grafana-pd-dashboard.md | 2 +- pd-control.md | 2 +- troubleshoot-hot-spot-issues.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/grafana-pd-dashboard.md b/grafana-pd-dashboard.md index c3501b4d15ac4..0a96e4c495a74 100644 --- a/grafana-pd-dashboard.md +++ b/grafana-pd-dashboard.md @@ -89,7 +89,7 @@ The following is the description of PD Dashboard metrics items: - Total read bytes on hot peer Regions: The total read bytes of peers that have become read hotspots on each TiKV instance - Store read rate bytes: The total read bytes of each TiKV instance - Store read rate keys: The total read keys of each TiKV instance -- Store read cpu: The read CPU usage of each TiKV instance. PD uses this metric for CPU-aware read hotspot scheduling starting from v8.5.7. +- Store read cpu: The read CPU usage of each TiKV instance. PD uses this metric for CPU-aware read hotspot scheduling starting from v8.5.7 and v9.0.0. - Hot cache read entry number: The number of peers that are in the read hotspot statistics module on each TiKV instance ![PD Dashboard - Hot read metrics](/media/pd-dashboard-hotread-v4.png) diff --git a/pd-control.md b/pd-control.md index 28fa218f5091d..72b180e5d0510 100644 --- a/pd-control.md +++ b/pd-control.md @@ -548,7 +548,7 @@ Usage: } ``` -Starting from v8.5.7, the `hot read` and `hot history` commands include `flow_cpu`, and the `hot store` command includes `cpu-read-rate`. These fields show the read CPU usage for CPU-aware read hotspot scheduling. +Starting from v8.5.7 and v9.0.0, the `hot read` and `hot history` commands include `flow_cpu`, and the `hot store` command includes `cpu-read-rate`. These fields show the read CPU usage for CPU-aware read hotspot scheduling. ### `label [store ]` diff --git a/troubleshoot-hot-spot-issues.md b/troubleshoot-hot-spot-issues.md index 44f4325970106..99e0bd8d13220 100644 --- a/troubleshoot-hot-spot-issues.md +++ b/troubleshoot-hot-spot-issues.md @@ -185,7 +185,7 @@ For more details, see [Coprocessor Cache](/coprocessor-cache.md). In a read hotspot scenario, the hotspot TiKV node cannot process read requests in time, resulting in the read requests queuing. However, not all TiKV resources are exhausted at this time. To reduce latency, TiDB v7.1.0 introduces the load-based replica read feature, which allows TiDB to read data from other TiKV nodes without queuing on the hotspot TiKV node. You can control the queue length of read requests using the [`tidb_load_based_replica_read_threshold`](/system-variables.md#tidb_load_based_replica_read_threshold-new-in-v700) system variable. When the estimated queue time of the leader node exceeds this threshold, TiDB prioritizes reading data from follower nodes. This feature can improve read throughput by 70% to 200% in a read hotspot scenario compared to not scattering read hotspots. -Starting from v8.5.7, PD supports CPU-aware Hot Region scheduling for read hotspots. TiKV reports per-Region read CPU usage in store heartbeats, and PD can use CPU usage as a scheduling dimension. This helps PD identify read hotspots whose QPS or byte throughput looks balanced but whose TiKV CPU usage is still uneven, such as workloads with different CPU-cost queries or clusters with different TiKV performance profiles. +Starting from v8.5.7 and v9.0.0, PD supports CPU-aware hot Region scheduling for read hotspots. TiKV reports per-Region read CPU usage in store heartbeats, and PD can use CPU usage as a scheduling dimension. This helps PD identify read hotspots whose QPS or byte throughput looks balanced but whose TiKV CPU usage is still uneven, such as workloads with queries that have different CPU costs or clusters with heterogeneous TiKV hardware. For clusters that support read CPU reporting, the default `read-priorities` value of `balance-hot-region-scheduler` is `cpu,byte`. For clusters that do not support read CPU reporting, PD automatically falls back to `query,byte`, or to `byte,key` if the cluster does not support the `query` dimension either. To view or adjust the scheduling dimensions, use [`pd-ctl scheduler config balance-hot-region-scheduler`](/pd-control.md#scheduler-config-balance-hot-region-scheduler). From 839939948cb4196bc6add51ab8884ceef6468925 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Thu, 2 Jul 2026 13:37:28 +0800 Subject: [PATCH 4/9] split one paragraph into two bullets and a smaller paragraph --- troubleshoot-hot-spot-issues.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/troubleshoot-hot-spot-issues.md b/troubleshoot-hot-spot-issues.md index 99e0bd8d13220..2eb8c1182c851 100644 --- a/troubleshoot-hot-spot-issues.md +++ b/troubleshoot-hot-spot-issues.md @@ -187,7 +187,10 @@ In a read hotspot scenario, the hotspot TiKV node cannot process read requests i Starting from v8.5.7 and v9.0.0, PD supports CPU-aware hot Region scheduling for read hotspots. TiKV reports per-Region read CPU usage in store heartbeats, and PD can use CPU usage as a scheduling dimension. This helps PD identify read hotspots whose QPS or byte throughput looks balanced but whose TiKV CPU usage is still uneven, such as workloads with queries that have different CPU costs or clusters with heterogeneous TiKV hardware. -For clusters that support read CPU reporting, the default `read-priorities` value of `balance-hot-region-scheduler` is `cpu,byte`. For clusters that do not support read CPU reporting, PD automatically falls back to `query,byte`, or to `byte,key` if the cluster does not support the `query` dimension either. To view or adjust the scheduling dimensions, use [`pd-ctl scheduler config balance-hot-region-scheduler`](/pd-control.md#scheduler-config-balance-hot-region-scheduler). +- For clusters that support read CPU reporting, the default `read-priorities` value of `balance-hot-region-scheduler` is `cpu,byte`. +- For clusters that do not support read CPU reporting, PD automatically falls back to `query,byte`, or to `byte,key` if the cluster does not support the `query` dimension either. + +To view or adjust the scheduling dimensions, use [`pd-ctl scheduler config balance-hot-region-scheduler`](/pd-control.md#scheduler-config-balance-hot-region-scheduler). ## Use TiKV MVCC in-memory engine to mitigate read hotspots caused by high MVCC read amplification From 35db21273bd6f5048cfb508f55e39e2e63eb81d5 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Thu, 2 Jul 2026 13:37:44 +0800 Subject: [PATCH 5/9] minor wording updates --- troubleshoot-hot-spot-issues.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/troubleshoot-hot-spot-issues.md b/troubleshoot-hot-spot-issues.md index 2eb8c1182c851..70766d4aa8a50 100644 --- a/troubleshoot-hot-spot-issues.md +++ b/troubleshoot-hot-spot-issues.md @@ -185,7 +185,7 @@ For more details, see [Coprocessor Cache](/coprocessor-cache.md). In a read hotspot scenario, the hotspot TiKV node cannot process read requests in time, resulting in the read requests queuing. However, not all TiKV resources are exhausted at this time. To reduce latency, TiDB v7.1.0 introduces the load-based replica read feature, which allows TiDB to read data from other TiKV nodes without queuing on the hotspot TiKV node. You can control the queue length of read requests using the [`tidb_load_based_replica_read_threshold`](/system-variables.md#tidb_load_based_replica_read_threshold-new-in-v700) system variable. When the estimated queue time of the leader node exceeds this threshold, TiDB prioritizes reading data from follower nodes. This feature can improve read throughput by 70% to 200% in a read hotspot scenario compared to not scattering read hotspots. -Starting from v8.5.7 and v9.0.0, PD supports CPU-aware hot Region scheduling for read hotspots. TiKV reports per-Region read CPU usage in store heartbeats, and PD can use CPU usage as a scheduling dimension. This helps PD identify read hotspots whose QPS or byte throughput looks balanced but whose TiKV CPU usage is still uneven, such as workloads with queries that have different CPU costs or clusters with heterogeneous TiKV hardware. +Starting from v8.5.7 and v9.0.0, PD supports CPU-aware hot Region scheduling for read hotspots. TiKV reports per-Region read CPU usage in store heartbeats, and PD can use CPU usage as a scheduling dimension. This mechanism helps PD identify read hotspots whose QPS or byte throughput looks balanced but whose TiKV CPU usage is still uneven, such as workloads with queries that have different CPU costs or clusters with heterogeneous TiKV hardware. - For clusters that support read CPU reporting, the default `read-priorities` value of `balance-hot-region-scheduler` is `cpu,byte`. - For clusters that do not support read CPU reporting, PD automatically falls back to `query,byte`, or to `byte,key` if the cluster does not support the `query` dimension either. From 4f62b65b61bda9a12b135612bb613d1738dcbd15 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Thu, 2 Jul 2026 14:31:11 +0800 Subject: [PATCH 6/9] Update pd-control.md --- pd-control.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pd-control.md b/pd-control.md index 72b180e5d0510..d28913dd1ef4e 100644 --- a/pd-control.md +++ b/pd-control.md @@ -1077,7 +1077,7 @@ Usage: scheduler config balance-hot-region-scheduler set min-hot-query-rate 10 ``` -- `min-hot-cpu-rate` specifies the minimum CPU usage of read requests to count, which is usually 10. +- `min-hot-cpu-rate` specifies the minimum CPU usage of read requests to count. The value is measured as a percentage of one CPU core, and the default value is usually `10`, which means 10% of one CPU core. ```bash scheduler config balance-hot-region-scheduler set min-hot-cpu-rate 10 From a62db8982013fcef628daae6968c0c9aa7fc8b99 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Thu, 2 Jul 2026 14:36:45 +0800 Subject: [PATCH 7/9] Update troubleshoot-hot-spot-issues.md --- troubleshoot-hot-spot-issues.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/troubleshoot-hot-spot-issues.md b/troubleshoot-hot-spot-issues.md index 70766d4aa8a50..a2a432c62cb3f 100644 --- a/troubleshoot-hot-spot-issues.md +++ b/troubleshoot-hot-spot-issues.md @@ -185,7 +185,7 @@ For more details, see [Coprocessor Cache](/coprocessor-cache.md). In a read hotspot scenario, the hotspot TiKV node cannot process read requests in time, resulting in the read requests queuing. However, not all TiKV resources are exhausted at this time. To reduce latency, TiDB v7.1.0 introduces the load-based replica read feature, which allows TiDB to read data from other TiKV nodes without queuing on the hotspot TiKV node. You can control the queue length of read requests using the [`tidb_load_based_replica_read_threshold`](/system-variables.md#tidb_load_based_replica_read_threshold-new-in-v700) system variable. When the estimated queue time of the leader node exceeds this threshold, TiDB prioritizes reading data from follower nodes. This feature can improve read throughput by 70% to 200% in a read hotspot scenario compared to not scattering read hotspots. -Starting from v8.5.7 and v9.0.0, PD supports CPU-aware hot Region scheduling for read hotspots. TiKV reports per-Region read CPU usage in store heartbeats, and PD can use CPU usage as a scheduling dimension. This mechanism helps PD identify read hotspots whose QPS or byte throughput looks balanced but whose TiKV CPU usage is still uneven, such as workloads with queries that have different CPU costs or clusters with heterogeneous TiKV hardware. +Starting from v8.5.7 and v9.0.0, PD supports CPU-aware hot Region scheduling for read hotspots. TiKV reports per-Region read CPU usage in store heartbeats, and PD can use CPU usage as a scheduling dimension. This mechanism helps PD identify read hotspots whose QPS or byte throughput appears balanced but whose TiKV CPU usage remains uneven, such as workloads with queries that have different CPU costs or clusters where TiKV nodes handle different workload patterns. - For clusters that support read CPU reporting, the default `read-priorities` value of `balance-hot-region-scheduler` is `cpu,byte`. - For clusters that do not support read CPU reporting, PD automatically falls back to `query,byte`, or to `byte,key` if the cluster does not support the `query` dimension either. From a882cee4528ae659b32de9201e7b7b4d68ea4e0b Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Thu, 2 Jul 2026 15:03:45 +0800 Subject: [PATCH 8/9] Update pd-control.md --- pd-control.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pd-control.md b/pd-control.md index d28913dd1ef4e..4ff6783830d9c 100644 --- a/pd-control.md +++ b/pd-control.md @@ -548,7 +548,7 @@ Usage: } ``` -Starting from v8.5.7 and v9.0.0, the `hot read` and `hot history` commands include `flow_cpu`, and the `hot store` command includes `cpu-read-rate`. These fields show the read CPU usage for CPU-aware read hotspot scheduling. +Starting from v8.5.7 and v9.0.0, the output of the `hot read` and `hot history` commands includes the `flow_cpu` field, and the output of the `hot store` command includes the `cpu-read-rate` field. These fields show the read CPU usage for CPU-aware read hotspot scheduling. ### `label [store ]` From 6324d4f0fba93fd9bbe2e32e5cb14fbead2bf14b Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Thu, 2 Jul 2026 15:09:10 +0800 Subject: [PATCH 9/9] Update pd-control.md --- pd-control.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pd-control.md b/pd-control.md index 4ff6783830d9c..4ddb31b5f7b67 100644 --- a/pd-control.md +++ b/pd-control.md @@ -1117,7 +1117,7 @@ Usage: > > If a cluster component is earlier than v5.2, the configuration of the `query` dimension does not take effect. If some components are upgraded to v5.2 or later, the `byte` and `key` dimensions still by default have the priority for hot Region scheduling. After all components of the cluster are upgraded to v5.2 or later, such a configuration still takes effect for compatibility. > - > Starting from v8.5.7, TiKV reports read CPU usage for hot Region scheduling. For clusters that support read CPU reporting, the default `read-priorities` value is `cpu,byte`. For clusters that do not support read CPU reporting, PD automatically falls back to `query,byte`, or to `byte,key` if the cluster does not support the `query` dimension either. You can view the real-time configuration using the `pd-ctl` command. Usually, you do not need to modify these configurations. + > Starting from v8.5.7 and v9.0.0, TiKV reports read CPU usage for hot Region scheduling. For clusters that support read CPU reporting, the default `read-priorities` value is `cpu,byte`. For clusters that do not support read CPU reporting, PD automatically falls back to `query,byte`, or to `byte,key` if the cluster does not support the `query` dimension either. You can view the real-time configuration using the `pd-ctl` command. Usually, you do not need to modify these configurations. ```bash scheduler config balance-hot-region-scheduler set read-priorities cpu,byte