为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。
- 【TiDB 版本】:4.0.0
- 【问题描述】: DM2.0 合库合表, 然后loader阶段, pool-size: 8 为什么qps一直跑不 上去,才几个,然后druation慢慢一直增加。
若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。
为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。
大量的连接线程,info 处于commit状态,tidb4.0 9个tikv,128GB内存主机, block-cache配置为32GB
Hi,可以检查一下dump文件(默认在worker目录的dump data下)的文件个数、大小吗。如果文件数目过小、文件过大,可能会影响速度,需要在 task 配置里的 extra-args 改为 extra-args: “–statement-size 1000000”
下个版本我们会自动处理好默认参数配置
之前64MB一个的时候,总的应该是一万个左右吧, 然后我今天换成3.1.2的版本了, 然后又报一个事务太大的错, 我就把DM的chunk-filesize: 32 从64改成32, 然后总数是 17592个 ,你的意思是文件数目过小,文件过大?会影响吗? 然后我今天换成3.1.2的报"RawCause": “Error 8004: transaction too large, len:300001”, 这个错,有什么办法吗, 我这边的情况就是就是4.0的太慢,现在换成3.1.2的报事务太大。 分别有解决方法吗
extra-args: “–statement-size 1000000”
这个参数可以解决 3.1 超出 30w 行的问题,可以适当调整,具体参数含义可以看下官网。
建议继续使用 4.0 版本,可以上传下 tidb 集群的 overview 面板的完整截图我们看下 tidb 的基本情况,
dm 导入较慢,出了 dm 本身参数设置,也需要关注下游 tidb 的状态
TIDB表如果没有显式设置主键,有没有关系?会自动生成rowid做主键吗? 因为合表问题,主键会有冲突。
extra-args: “–statement-size 1000000” 这个参数我看mydumper默认就是1000000, 要设置成多少呢?
应该是 load 的热点问题,dm 2.0 将 mydumper 换成了 dumpling:此参数的含义是: 控制 INSERT
SQL 语句的大小,单位 bytes
512 或者 1024 试下,如果表较多,调整到原来的一半 500000 试下。满足 30w 行限制即可。
overview - system info 信息没有看到可以再截图看下。
从监控看到 hot region 较多,根据以下链接调整下:
https://docs.pingcap.com/zh/tidb/stable/troubleshoot-hot-spot-issues/#tidb-热点问题处理
https://docs.pingcap.com/zh/tidb/stable/high-concurrency-best-practices/#热点产生的实例