tidb: global memory arbitrator mechanism#22882
Conversation
|
Note Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported. |
Synced from: pingcap/docs-cn#20955 Target PR: pingcap#22882 AI Provider: azure Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
|
Auto-sync completed successfully Source PR: pingcap/docs-cn#20955 English documentation has been updated based on Chinese documentation changes. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
@solotzg: adding LGTM is restricted to approvers and reviewers in OWNERS files. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Update documentation references to use the new "memory arbitrator" naming and corrected anchor targets. Changed cross-doc links in configure-memory-usage.md and system-variables.md (e.g. tidb_mem_arbitrator_mode anchor, memory-arbitrator-mode anchor, and the high-memory alarm anchor) so they point to the renamed headings introduced for v9.0.0 and ensure consistent phrasing across the docs.
|
|
||
| - When the memory usage of a TiDB instance exceeds the limit, TiDB might randomly terminate running SQL statements. | ||
| - Memory resources follow a "use-then-report" mechanism, and memory usage is isolated across different SQL statements. As a result, TiDB cannot centrally schedule or control memory resources at the instance level. | ||
| - Under high memory pressure, the overhead of Go garbage collection (Garbage Collection, GC) increases significantly, and in severe cases might cause out of memory (OOM) issues. |
There was a problem hiding this comment.
| - Under high memory pressure, the overhead of Go garbage collection (Garbage Collection, GC) increases significantly, and in severe cases might cause out of memory (OOM) issues. | |
| - Under high memory pressure, the overhead of Go garbage collection (GC) increases significantly, and in severe cases might cause out of memory (OOM) issues. |
| - [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) | ||
| - [`max_execution_time`](/system-variables.md#max_execution_time) | ||
|
|
||
| When memory resources are insufficient or there is an OOM risk, the arbitrator can reclaim memory resources by terminating SQL, but it does not terminate `DDL`, `DCL`, or `TCL` SQL types. Terminated SQL returns error code `8180` to the client. The error format is: `Query execution was stopped by the global memory arbitrator [reason=?, path=?] [conn=?]`. The related fields are explained as follows: |
There was a problem hiding this comment.
| When memory resources are insufficient or there is an OOM risk, the arbitrator can reclaim memory resources by terminating SQL, but it does not terminate `DDL`, `DCL`, or `TCL` SQL types. Terminated SQL returns error code `8180` to the client. The error format is: `Query execution was stopped by the global memory arbitrator [reason=?, path=?] [conn=?]`. The related fields are explained as follows: | |
| When memory resources are insufficient or there is an OOM risk, the arbitrator can reclaim memory resources by terminating SQL statements, but it does not terminate `DDL`, `DCL`, or `TCL` SQL statements. Terminated SQL returns error code `8180` to the client. The error format is: `Query execution was stopped by the global memory arbitrator [reason=?, path=?] [conn=?]`. The related fields are explained as follows: |
| Before TiDB v9.0.0, the [memory control mechanism](#configure-the-memory-usage-threshold-of-a-tidb-server-instance) has the following issues: | ||
|
|
||
| - When the memory usage of a TiDB instance exceeds the limit, TiDB might randomly terminate running SQL statements. | ||
| - Memory resources follow a "use-then-report" mechanism, and memory usage is isolated across different SQL statements. As a result, TiDB cannot centrally schedule or control memory resources at the instance level. |
There was a problem hiding this comment.
| - Memory resources follow a "use-then-report" mechanism, and memory usage is isolated across different SQL statements. As a result, TiDB cannot centrally schedule or control memory resources at the instance level. | |
| - Memory resources follow a "use first and report later" mechanism, and memory usage is isolated across different SQL statements. As a result, TiDB cannot centrally schedule or control memory resources at the instance level. |
There was a problem hiding this comment.
reason: to be consistent with the description of tidb_mem_arbitrator_mode
| - Unit: Threads | ||
| - This variable is used to set the maximum concurrency for TiFlash to execute a request. The default value is `-1`, indicating that this system variable is invalid and the maximum concurrency depends on the setting of the TiFlash configuration `profiles.default.max_threads`. When the value is `0`, the maximum number of threads is automatically configured by TiFlash. | ||
|
|
||
| ### `tidb_mem_arbitrator_mode` <span class="version-mark">New in v9.0.0</span> |
There was a problem hiding this comment.
| ### `tidb_mem_arbitrator_mode` <span class="version-mark">New in v9.0.0</span> | |
| ### tidb_mem_arbitrator_mode <span class="version-mark">New in v9.0.0</span> |
| - `standard`: Enables standard memory arbitrator mode. When SQL needs to use memory resources, it first subscribes to the memory arbitrator and allocates memory resources only after the subscription succeeds. If the subscription fails, the SQL execution is terminated. | ||
| - `priority`: Enables priority-based memory arbitrator mode. When SQL needs to use memory resources, it first subscribes to the memory arbitrator and allocates memory resources only after the subscription succeeds. TiDB handles memory resource subscription requests according to the SQL [resource group priority](/information-schema/information-schema-resource-groups.md). | ||
|
|
||
| ### `tidb_mem_arbitrator_query_reserved` <span class="version-mark">New in v9.0.0</span> |
There was a problem hiding this comment.
| ### `tidb_mem_arbitrator_query_reserved` <span class="version-mark">New in v9.0.0</span> | |
| ### tidb_mem_arbitrator_query_reserved <span class="version-mark">New in v9.0.0</span> |
| - Range: `[0, 9223372036854775807]` | ||
| - When [memory arbitrator mode](/configure-memory-usage.md#memory-arbitrator-mode) is enabled, this variable controls the amount of memory resources that SQL pre-subscribes to from the memory arbitrator before execution. For more information, see [TiDB memory control](/configure-memory-usage.md#manually-ensuring-memory-safety). | ||
|
|
||
| ### `tidb_mem_arbitrator_soft_limit` <span class="version-mark">New in v9.0.0</span> |
There was a problem hiding this comment.
| ### `tidb_mem_arbitrator_soft_limit` <span class="version-mark">New in v9.0.0</span> | |
| ### tidb_mem_arbitrator_soft_limit <span class="version-mark">New in v9.0.0</span> |
| - Floating-point number `(0, 1]`: Specifies the upper limit of memory resources as a ratio relative to [`tidb_server_memory_limit`](/system-variables.md#tidb_server_memory_limit-new-in-v640). For example, `0.8` means the upper limit of memory resources is `tidb_server_memory_limit * 0.8`. | ||
| - Integer `(1, 9223372036854775807]`: Specifies the number of bytes. | ||
|
|
||
| ### `tidb_mem_arbitrator_wait_averse` <span class="version-mark">New in v9.0.0</span> |
There was a problem hiding this comment.
| ### `tidb_mem_arbitrator_wait_averse` <span class="version-mark">New in v9.0.0</span> | |
| ### tidb_mem_arbitrator_wait_averse <span class="version-mark">New in v9.0.0</span> |
[LGTM Timeline notifier]Timeline:
|
This PR is translated from: pingcap/docs-cn#20955
First-time contributors' checklist
What is changed, added or deleted? (Required)
Add documentation for the TiDB global memory arbitrator mode, including:
standardandprioritymodes.tidb_mem_arbitrator_mode: sets the global memory management mode for a TiDB instance.tidb_mem_arbitrator_query_reserved: sets the amount of memory reserved in advance for a SQL statement before execution.tidb_mem_arbitrator_soft_limit: sets the upper limit of memory allocation for a TiDB instance.tidb_mem_arbitrator_wait_averse: controls the behavior of SQL statements when waiting for memory resources, including the meanings of the values0(default, disabled),1, andnolimit.Which TiDB version(s) do your changes apply to? (Required)
Tips for choosing the affected version(s):
By default, CHOOSE MASTER ONLY so your changes will be applied to the next TiDB major or minor releases. If your PR involves a product feature behavior change or a compatibility change, CHOOSE THE AFFECTED RELEASE BRANCH(ES) AND MASTER.
For details, see tips for choosing the affected versions (in Chinese).
What is the related PR or file link(s)?
Do your changes match any of the following descriptions?