load data local导致大量regionMiss

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】

4.0.9
【概述】 场景 + 问题概述
监控中显示每整点时有大量 regionmiss ,分析慢日志发现有如下 SQL
load data local infile xxx
这个 SQL 执行时间 228 秒(也有个别 load 语句执行了几千秒),这个 SQL 在慢日志中显示了大量 regionMiss 关键字,统计后,共计 21817 个 regionMiss 关键字,仅仅这一个load语句,就这么多个 regionMiss 关键字。

集群状态算是正常,没有节点下线和OOM之类的,通过监控看到,各个节点leader的数量在同个时间段没有抖动现象,很平稳。duration有一点尖刺,说明load操作对集群应该有点影响。
同时发现相应时间段内,网卡流量,tcp retrans,IO util出现一个尖刺,峰值。

我的问题是:
(1)像这种大量 regionMiss 会导致集群什么问题?需要关注吗?
(2)像这种 load 操作需要拆分成小文件导入吗?需要优化吗?
(3)大的事务在tidb上最大的问题是什么?类上面load操作

请帮忙解答一下,谢谢

【背景】 做过哪些操作

慢 SQL 如下所示,省略了部分 regionMiss 关键字,因为太多了。

Time: 2022-01-29T13:57:32.276797564+08:00

Txn_start_ts: 0

User@Host: ad_w[ad_w] @ 10.30.1.106 [10.30.1.106]

Conn_ID: 124758945

Query_time: 228.417722959

Parse_time: 0.000151069

Compile_time: 0.00012463

Rewrite_time: 0.000095709

Prewrite_time: 57.333421602 Commit_time: 2.097102984 Get_commit_ts_time: 0.021664947 Commit_backoff_time: 47.004 Backoff_types: [regionMiss regionMiss regionMiss regionMiss regionMiss regionMiss regionMiss regionMiss

… 这里省略了大量 regionMiss 关键字,共计 21817 个。
] Write_keys: 4293582 Write_size: 2214438986 Prewrite_region: 22413

DB: ad

Is_internal: false

Digest: dfd48deeb71f43343f731bc2572fbd31c539267e8ad7dde7d9f04bfb4cacbdb1

Num_cop_tasks: 0

Prepared: false

Plan_from_cache: false

Has_more_results: false

KV_total: 907.205072586

PD_total: 0.032086503

Backoff_total: 47.01

Write_sql_response_total: 0

Succ: true

Plan: tidb_decode_plan(

use ad;
load data local infile ‘/data/data1/tmp/part-00000’ into table ad.dim_ad_wise character set utf8 fields terminated by ‘\t’ lines terminated by ’ ’ (xx,xx,xx,xx);

【现象】 业务和数据库现象

【问题】 当前遇到的问题

【业务影响】

【TiDB 版本】
4.0.9
【应用软件及版本】

【附件】 相关日志及配置信息

  • TiUP Cluster Display 信息
  • TiUP CLuster Edit config 信息

监控(https://metricstool.pingcap.com/)

  • TiDB-Overview Grafana监控
  • TiDB Grafana 监控
  • TiKV Grafana 监控
  • PD Grafana 监控
  • 对应模块日志(包含问题前后 1 小时日志)

若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

1 个赞

(1)像这种大量 regionMiss 会导致集群什么问题?需要关注吗?
在读写的时候,会引发各种 backoff,会影响效率(可以参考你自己贴出的日志,基本上backoff 会占用很长时间)

(2)像这种 load 操作需要拆分成小文件导入吗?需要优化吗?
数据导入,需要根据你的实际环境和要求来定的,可以参考官方文档提供的数据来优化

(3)大的事务在tidb上最大的问题是什么?类上面load操作
最大的问题是物理内存不足,导致 OOM,或者事务失败

参考以下的参数:


https://docs.pingcap.com/zh/tidb/stable/tidb-configuration-file/#txn-total-size-limit

https://docs.pingcap.com/zh/tidb/stable/transaction-overview/#事务限制

image
https://docs.pingcap.com/zh/tidb/stable/migration-tidb-faq/#transaction-too-large-是什么原因怎么解决

如果更严重,会出现 backoff 超时,参考这篇文档:

3 个赞

多谢答复

【大事务危害】
(1)耗费更多内存,对于写入要先缓存到tidb server,对于读取要在tidb server计算
(2)网卡流量会有一个尖刺峰值出现,可能影响集群
(3)tikv IO可能会有尖刺峰值出现
(4)tcp retrans 增多
tcp retrans 增多可能正式由于第(2)项导致的,会影响系统交互的效率,从而影响集群性能
总结下来就是:大事务对内存、网卡、磁盘IO都有影响,因此应该避免大事务,虽然支持大事务。

不知道对不对。

1 个赞

大事务不是危害,是一种场景,在未来肯定会被支持;
目前这种场景也有金融行业出现,比较常见,目前对于资源的消耗比较大,最主要的消耗在内存
CPU,网络一般的情况下都足够支持的,对于特殊的峰值一定要做好预测和压测,避免出现这种极端情况

目前 tidb 已经上了 cloud 服务,对于k8s 的支持也更加完善,对于这种场景将来也是可以更好的支持,值得期待

1 个赞

如果可以的话,建议尽量缩小事务的大小,把文件拆成多个会比较好。

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。