【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
文档：
使用 --ratelimit 参数对备份任务进行限速。请注意，这个参数限制的是把备份文件存储到外部存储的速度。计算备份文件的大小时，请以备份日志中的 backup data size(after compressed) 为准。设置 --ratelimit 后，为了避免任务数过多导致限速失效，br 的 concurrency 参数会自动调整为 1。
问题：
ratelimit限制的是最大速度，br 的 concurrency 参数会自动调整为 1。实际观察下来，备份期间90%的流量很少，远远达不到ratelimit的值，导致备份时间很长。
在备份窗口，其实是可以允许在ratelimit的流量负载下长时间运行的。限制了速度并发自动调整为1后，在备份窗口就无法完成备份。
有没有好的办法既可以限制速度，又可以缩短备份时间？
不写ratelimit，自己测试不同的concurrency值
1 个赞
不用ratelimit参数，改SHOW config WHERE NAME LIKE ‘%backup.num-threads%’
这个参数呗
1 个赞
–concurrency uint32 The size of a BR thread pool that executes tasks, One task represents one table range (or one index range) according to the backup schemas. If there is one table with one index.there will be two tasks to back up this table. This value should increase if you need to back up lots of tables or indices. (default 4)
用于 BR 备份相关的配置项。
num-threads
处理备份的工作线程数量。
默认值：CPU * 0.5，但最大为 8
可调整范围：[1, CPU]
最小值：1
这两个参数怎么理解
是不是总分的关系。
我自己在腾讯云上的备份实践是，这个ratelimit必须要有，可以让速度慢一点，不过一旦让br把带宽全部吃掉，会导致br连不上pd，然后备份失败。
我觉得其他参数的调整可以先放一放，优先看看当前环境去掉ratelimit后会不会导致上述问题。如果说会出现上面这个问题，调其他参数的意义也就不大了。
这种情况会不会是某个热点节点拉慢了整体备份速度了呢
有没有试过给网卡限速，一步到位， 就是影响比较大。