backup: adjust concurrency description after v8.2 #20963
Conversation
|
[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.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
ti-chi-bot
bot
added
missing-translation-status
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hello @3pointer, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
Summary of Changes
Hello! Gemini here, providing a summary of this pull request. This PR focuses on updating the documentation for the br (Backup & Restore) tool, specifically clarifying the roles and recommended usage of the --ratelimit and --concurrency parameters when controlling backup performance and impact on the cluster. It removes the --ratelimit parameter from several example commands and revises the guidance on performance tuning, emphasizing the tikv.backup.num-threads configuration as the primary method.
Highlights
- Documentation Update: Updates the documentation for the
brtool, specifically related to backup performance tuning parameters. - Clarified Parameter Usage: Provides clearer explanations for the
--ratelimitand--concurrencyparameters, detailing their actual effect on backup tasks. - Performance Tuning Recommendation: Recommends using the TiKV configuration parameter
backup.num-threadsas the primary method for controlling backup impact and performance, rather than thebrcommand-line parameters. - Example Command Updates: Removes the
--ratelimitparameter from several exampletiup br backupcommands in the documentation.
Changelog
Click here to see the changelog
- br/br-snapshot-guide.md
- Removed
--ratelimit 128from the exampletiup br backup fullcommand. - Removed the description for the
--ratelimitparameter. - Revised the section on controlling backup impact, recommending
tikv.backup.num-threadsas the primary method and explaining--ratelimitas an alternative with caveats.
- Removed
- br/br-snapshot-manual.md
- Removed
--ratelimit 128from the exampletiup br backup fullcommand. - Removed the description for the
--ratelimitparameter. - Removed
--ratelimit 128from the exampletiup br backup dbcommand. - Removed
--ratelimit 128from the exampletiup br backup tablecommand. - Removed
--ratelimit 128from the exampletiup br backup fullcommand with filtering.
- Removed
- br/use-br-command-line-tool.md
- Updated the description for the
--concurrencyparameter to clarify its role in request splitting and recommendtikv.backup.num-threadsfor performance tuning.
- Updated the description for the
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
This pull request provides a valuable update to the documentation for BR's --ratelimit and --concurrency parameters. The changes significantly improve clarity by:
- Recommending
backup.num-threadsas the primary method for controlling backup impact, and positioning--ratelimitas an alternative for specific scenarios. - Clarifying the current role and effect of the
--concurrencyparameter.
The updated descriptions are more informative and will help users better understand how to manage backup performance and resource utilization. The changes generally adhere to the TiDB Documentation Style Guide.
I have a few minor suggestions for further refinement, mostly related to consistency and formatting. Overall, this is a good improvement to the documentation.
The review was guided by the TiDB Documentation Style Guide, focusing on:
- Clarity, Simplicity, Completeness, and Readability (Style Guide Line 14): Ensuring the updated descriptions for
ratelimitandconcurrencyare easy for users to understand. - Technical Accuracy and Terminology Consistency (Style Guide Line 16): Verifying parameter names and their descriptions, leading to a suggestion for the
backup.num-threadslink text. - Avoiding Unnecessary Words/Repetition (Style Guide Line 24): Pointing out an extra space.
- Consistent Terminology (and by extension, formatting) (Style Guide Line 25): Suggesting consistent note formatting.
Summary of Findings
- Note Formatting Consistency: Suggested a minor change to note formatting for consistency across documentation files.
- Minor Typographical Error: Identified an extra space after a period that could be removed.
- Link Text Precision: Recommended updating link text to use the exact parameter name for improved technical accuracy.
Merge Readiness
The pull request significantly improves the documentation for BR's ratelimit and concurrency parameters. The changes are clear, accurate, and well-aligned with the project's direction for these features. I've made a few minor suggestions for consistency and formatting. After addressing these small points, or if they are deemed non-critical, the documentation should be in excellent shape. As per the repository's contribution guidelines, I am providing comments rather than requesting changes to avoid blocking the merge. The final decision to merge rests with the maintainers.
br/use-br-command-line-tool.md
Outdated
| @@ -57,7 +57,7 @@ | |||
| * `--cert`: specifies the path to the SSL certificate in the PEM format. | |||
| * `--key`: specifies the path to the SSL certificate key in the PEM format. | |||
| * `--status-addr`: specifies the listening address through which `br` provides statistics to Prometheus. | |||
| * `--concurrency`: the number of concurrent tasks during the backup. | |||
| * `--concurrency`: Controls how backup tasks are split into multiple requests and sent concurrently to the same TiKV node. This parameter primarily affects the granularity of request splitting from BR to TiKV, and no longer directly determines overall backup throughput. In most cases, it is unnecessary to change this value. To improve backup performance, it is recommended to tune [tikv.backup.num-threads](/tikv-configuration-file.md#num-threads-1) instead. | |||
There was a problem hiding this comment.
There's an extra space after the period before "In most cases". Could this be removed for cleaner formatting?1
Style Guide References
| * `--concurrency`: Controls how backup tasks are split into multiple requests and sent concurrently to the same TiKV node. This parameter primarily affects the granularity of request splitting from BR to TiKV, and no longer directly determines overall backup throughput. In most cases, it is unnecessary to change this value. To improve backup performance, it is recommended to tune [tikv.backup.num-threads](/tikv-configuration-file.md#num-threads-1) instead. | |
| * `--concurrency`: Controls how backup tasks are split into multiple requests and sent concurrently to the same TiKV node. This parameter primarily affects the granularity of request splitting from BR to TiKV, and no longer directly determines overall backup throughput. In most cases, it is unnecessary to change this value. To improve backup performance, it is recommended to tune [tikv.backup.num-threads](/tikv-configuration-file.md#num-threads-1) instead. |
Footnotes
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
hfxsd
added
translation/from-docs-cn
hfxsd
changed the title
|
@YuJuncen: adding LGTM is restricted to approvers and reviewers in OWNERS files. In 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. |
| @@ -247,8 +245,22 @@ To illustrate the impact of backup, this document lists the test conclusions of | |||
|
|
|||
| You can use the following methods to manually control the impact of backup tasks on cluster performance. However, these two methods also reduce the speed of backup tasks while reducing the impact of backup tasks on the cluster. | |||
|
|
|||
| - Use the `--ratelimit` parameter to limit the speed of backup tasks. Note that this parameter limits the speed of **saving backup files to external storage**. When calculating the total size of backup files, use the `backup data size(after compressed)` as a benchmark. When `--ratelimit` is set, to avoid too many tasks causing the speed limit to fail, the `concurrency` parameter of br is automatically adjusted to `1`. | |||
| - Adjust the TiKV configuration item [`backup.num-threads`](/tikv-configuration-file.md#num-threads-1) to limit the number of threads used by backup tasks. According to internal tests, when BR uses no more than `8` threads for backup tasks, and the total CPU utilization of the cluster does not exceed 60%, the backup tasks have little impact on the cluster, regardless of the read and write workload. | |||
| Recommendation: Adjust the TiKV configuration parameter [`backup.num-threads`](/tikv-configuration-file.md#num-threads-1), which controls the number of worker threads used by backup tasks. Since backup is a CPU-intensive operation, tuning this parameter allows for more precise control over TiKV’s CPU usage, enabling better resource isolation and predictability. | |||
There was a problem hiding this comment.
| Recommendation: Adjust the TiKV configuration parameter [`backup.num-threads`](/tikv-configuration-file.md#num-threads-1), which controls the number of worker threads used by backup tasks. Since backup is a CPU-intensive operation, tuning this parameter allows for more precise control over TiKV’s CPU usage, enabling better resource isolation and predictability. | |
| - Recommended method: Adjust the TiKV configuration parameter [`backup.num-threads`](/tikv-configuration-file.md#num-threads-1), which controls the number of worker threads used by backup tasks. Because backup is a CPU-intensive operation, tuning this parameter allows for more precise control over TiKV’s CPU usage, enabling better resource isolation and predictability. In most scenarios, simply adjusting `num-threads` is sufficient to limit the impact of backup on the cluster. Internal testing shows that when the number of threads is set to `8` or fewer, and overall cluster CPU usage remains below 60%, the impact of backup on foreground workloads is negligible. |
|
|
||
| In most scenarios, simply adjusting `num-threads` is sufficient to limit the impact of backup on the cluster. Internal testing shows that when the number of threads is set to 8 or fewer, and overall cluster CPU usage remains below 60%, the impact of backup on foreground workloads is negligible. |
There was a problem hiding this comment.
| In most scenarios, simply adjusting `num-threads` is sufficient to limit the impact of backup on the cluster. Internal testing shows that when the number of threads is set to 8 or fewer, and overall cluster CPU usage remains below 60%, the impact of backup on foreground workloads is negligible. |
|
|
||
| When enabled, BR will automatically set `--concurrency` to 1 to reduce the number of concurrent requests. |
There was a problem hiding this comment.
| When enabled, BR will automatically set `--concurrency` to 1 to reduce the number of concurrent requests. |
|
|
||
| In most scenarios, simply adjusting `num-threads` is sufficient to limit the impact of backup on the cluster. Internal testing shows that when the number of threads is set to 8 or fewer, and overall cluster CPU usage remains below 60%, the impact of backup on foreground workloads is negligible. | ||
|
|
||
| Alternative: If you have already set `backup.num-threads` to a low value (e.g., 1) but still want to further reduce the impact of backup on the cluster, consider using the `--ratelimit` parameter. This option limits the bandwidth used to write backup files to external storage, specified in MiB/s. Note that the actual rate limiting effect depends on the size of the compressed data. You can refer to the `backup data size (after compressed)` field in the logs for more insight. |
There was a problem hiding this comment.
| Alternative: If you have already set `backup.num-threads` to a low value (e.g., 1) but still want to further reduce the impact of backup on the cluster, consider using the `--ratelimit` parameter. This option limits the bandwidth used to write backup files to external storage, specified in MiB/s. Note that the actual rate limiting effect depends on the size of the compressed data. You can refer to the `backup data size (after compressed)` field in the logs for more insight. | |
| - Alternative method: If you have already set `backup.num-threads` to a small value (for example, `1`), but still want to further reduce the impact of backup on the cluster, consider using the `--ratelimit` parameter. This option limits the bandwidth used to write backup files to external storage, specified in MiB/s. Note that the actual rate limiting effect depends on the size of the compressed data. You can refer to the `backup data size (after compressed)` field in the logs for more insight. When `--ratelimit` is enabled, BR automatically sets `--concurrency` to `1` to reduce the number of concurrent requests. |
| > | ||
| > In such situations, consider the following alternatives: | ||
| > | ||
| > - [Scale out a cluster](/tiup/tiup-component-cluster-scale-out.md) to increase available resources. |
There was a problem hiding this comment.
| > - [Scale out a cluster](/tiup/tiup-component-cluster-scale-out.md) to increase available resources. | |
| > - [Scale out a cluster](/tiup/tiup-cluster.md#scale-out-a-cluster) to increase available resources. |
| @@ -57,7 +57,7 @@ A `tiup br` command consists of multiple layers of sub-commands. Currently, br c | |||
| * `--cert`: specifies the path to the SSL certificate in the PEM format. | |||
| * `--key`: specifies the path to the SSL certificate key in the PEM format. | |||
| * `--status-addr`: specifies the listening address through which `br` provides statistics to Prometheus. | |||
| * `--concurrency`: the number of concurrent tasks during the backup. | |||
| * `--concurrency`: Controls how backup tasks are split into multiple requests and sent concurrently to the same TiKV node. This parameter primarily affects the granularity of request splitting from BR to TiKV, and no longer directly determines overall backup throughput. In most cases, it is unnecessary to change this value. To improve backup performance, it is recommended to tune [`backup.num-threads`](/tikv-configuration-file.md#num-threads-1) instead. | |||
There was a problem hiding this comment.
| * `--concurrency`: Controls how backup tasks are split into multiple requests and sent concurrently to the same TiKV node. This parameter primarily affects the granularity of request splitting from BR to TiKV, and no longer directly determines overall backup throughput. In most cases, it is unnecessary to change this value. To improve backup performance, it is recommended to tune [`backup.num-threads`](/tikv-configuration-file.md#num-threads-1) instead. | |
| * `--concurrency`: controls how backup tasks are split into multiple requests and sent concurrently to the same TiKV node. This parameter primarily affects the granularity of request splitting from BR to TiKV, and no longer directly determines overall backup throughput. In most cases, it is not necessary to change this value. To improve backup performance, it is recommended to tune [`tikv.backup.num-threads`](/tikv-configuration-file.md#num-threads-1) instead. |
First-time contributors' checklist
What is changed, added or deleted? (Required)
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.
What is the related PR or file link(s)?
Do your changes match any of the following descriptions?