Leader Balance 和 Region Balance 100%

这次涉及的表是 mongo_mobile_raw_data_mobile_details,我挑了两个速度差异明显的截图如下:

慢的那个查询时间及查询计划,

快的那个查询时间及查询计划,

查询计划是一样的,我检查下来找不出差别。

您好:

      1. explain sql对于相同的sql语句,执行计划应该是一样的,这里有可能是具体的where条件中代入值不同,导致扫描的key数量级相差比较大. 方便执行explain ananlze看下吗?
    
     2.  麻烦新的问题创建个新帖子,尽量一个问题在一个帖子里答复,这样方便其他人查看,并且追踪问题也会高效很多,多谢。

explain analyze …不是explain 这样后面会有具体的扫描行数。。可能就是楼上大佬说的 因为条件不一样 扫描的key 不同导致

好的。不过这不是新问题,是从标题那个问题追溯下来的。

这是最新执行时间 10秒多的那个的,

这是最新执行时间 0.074秒的那个的,

按这个扫描量级 应该不会这么慢啊。。。TIKV的配置都一样吗?

TiKV 的机型、配置完全一样。并且,同一台机器的其他实例也正常啊。

(不过,提醒一下后面看到这个帖子的人,慢的 store 会迁移,最开始在 172.16.150。92:20182,然后是 172.16.150.121:20180,现在是 172.16.150.121:20182)

方便提供一下 PD 监控面板中 Operator 和 Statistics-balance 相关的监控么,我这边看下 region 调度的情况会不会有影响

确认一下目前需要看的实际是两个问题是吧

第一个问题:往 TiDB 导入大量数据之后,查询变慢,从亚秒级变成了秒级的,相同的查询在满日中记录有执行 0 点几秒的,有执行十几秒的,手动执行的时候速度正常

第二个问题:从 95% Wait duration by store 监控看到,有某一个 store 比较慢,且这个 store 随着时间变化,会迁移。

关于第一个问题可以看下慢日志记录的信息,对应 0 点几秒和十几秒执行的 SQL 对应的耗时阶段是哪部分不同,定位到差异部分。v3.0.5 以上版本慢日志中会记录运行 SQL 当时的执行计划,可以判断是否有执行计划不稳定的问题,这边考虑升级集群吗?

关于第二个问题,从提供的 PD 监控看没有 Hot Region 的分布,目前查询慢的情况是一直出现还是导入完数据之后出现了一段时间,后续就正常了?

差不多是这样,慢的情况看起来是在 导入了大量数据 或者 是对要读取的表做了比较大的插入 操作之后比较明显。然后调查原因的时候,发现有一个 store 特别慢,看起来像是等待时间比较长,而且随着时间的变化,这个特别慢的 store 还会迁移。

没有大量数据写入的时候是会恢复的比较正常,查询变快,那个慢的 store 的 wait duration 短了很多。

升级集群的提议我们考虑一下。

导入完数据之后一个 store 特别慢,且随着时间变化,慢 store 会迁移,从现象看比较容易怀疑是 region 调度产生的影响,但是从提供的 PD 监控看是 last 1 hour 的监控信息,这个应该是已经恢复正常了的时候的监控了吧。

可以看下导入数据完成那段时间以及到慢 store 发生迁移到最终恢复正常这段时间的 region 调度情况 另外可以排查一下 TiKV-Detail 监控中慢 store 发生迁移时,除了 wait duration 监控指标外,还有什么指标也对应发生了迁移的

嗯,刚注意到慢 store 又发生了一次迁移。另外,有关 region 调度的历史记录从哪里可以获得?

  1. 请上传最近一次慢的情况发生时,一小时的监控信息,overview,tidb tikv-detail,disk-performance信息. (1)、chrome 安装这个插件https://chrome.google.com/webstore/detail/full-page-screen-capture/fdpohaocaechififmbbbbbknoalclacl

(2)、鼠标焦点置于 Dashboard 上,按 ?可显示所有快捷键,先按 d 再按 E 可将所有 Rows 的 Panels 打开,需等待一段时间待页面加载完成。

(3)、使用这个 full-page-screen-capture 插件进行截屏保存

  1. 上传这个时间段的tidb日志,

  2. 请查看集群中是否存在大的region ,反馈以下信息,多谢. 使用jq查询

./bin/pd-ctl -d region | jq “.regions | map(select(.approximate_size > 96)) | length”

./bin/pd-ctl -d region | jq “.regions | map(select(.approximate_size > 128)) | length”

./bin/pd-ctl -d region | jq “.regions | map(select(.approximate_size > 256)) | length”

./bin/pd-ctl -d region | jq “.regions | map(select(.approximate_size > 512)) | length”

现在集群的状况持续不太好,这是最近一个小时的监控,

日志上传在百度云盘,这是链接和提取码:
链接: https://pan.baidu.com/s/1f1OXs4q7mrXgx2trZaTdVg 提取码: dmnh
链接: https://pan.baidu.com/s/1aPZFLqIkckQUk_LLpRipkg 提取码: sfjp

麻烦把jq的信息也更新到帖子里,我先看下监控,多谢.

嗯嗯,这是 jq 查的信息:

  1. [“compile sql error”] [conn=1030644] [error="[parser:1149]syntax error, unexpected ‘?’"] [errorVerbose="[parser:1149]syntax error, unexpected 这种解析的sql报错很多,看下是否可以修改下.
  2. 从监控信息看,coprocessor慢,主要在wait duration慢
  3. 查看慢日志都是SELECT start_time, the_other_type FROM mongo.mongo_mobile_raw_data_mobile_details WHERE ((use_time > ‘xxx’)) AND ((orderid = ‘xxx’));
  4. 尝试先优化这些sql. 从历史记录看,某些数据的执行时间很长. Leader Balance 和 Region Balance 100% 请帮忙上传这个表的表结构,多谢,
  1. [“compile sql error”] [conn=1030644] [error="[parser:1149]syntax error, unexpected ‘?’"] [errorVerbose="[parser:1149]syntax error, unexpected 这种解析的sql报错很多,看下是否可以修改下.

SQL解析报错的问题我也很纳闷,一样的 SQL(不同的只有参数值),一会正常,一会报错。报错了的,手工执行也都是正常的。

另外,SQL 本身是优化过的(其实是同样的 SQL在不同的数据上跑),只是它执行不稳定,一会儿快一会慢。

[问题澄清]

数据库版本:V3.0.4 集群拓扑: 1个服务器部署了4个tikv实例 16core,128G

问题描述: tidb集群查询慢,并且会漂移到不同的store

[问题分析]

  1. 查看监控信息,发现主要慢在了coprocessor wait duration image
  2. 查看90 这个服务器的 coprocessor cpu ,达到了250%,查看配置文件中配置的是3,按理说没有到达瓶颈
  3. 查看所有服务器的cpu,发现总的cpu已经打满,导致coprocessor cpu在没有达到最大值时,已经到达瓶颈

[下步计划]

  1. 由分析中的1和2可以看出,存在热点情况,请先按照热点问题排查处理 https://github.com/pingcap-incubator/tidb-in-action/blob/master/session4/chapter7/hotspot-resolved.md
  2. 由分析中1,2,3看出集群已经到达瓶颈,这个时候,可以尝试先调整tikv参数配置:

[server] grpc-concurrency = 2

[raftstore] store-pool-size = 2 apply-pool-size = 1 raft-base-tick-interval = “2s”

[readpool.storage] high-concurrency = 1 normal-concurrency = 1 low-concurrency = 1

[storage] scheduler-worker-pool-size = 1

[readpool.coprocessor] # high-concurrency = 2 normal-concurrency = 4 low-concurrency = 4

这样调整是希望可以针对整体cpu不足,给coprocessor多一些cpu使用,不具有普遍操作意义。 从每个参数对应的cpu可以看出,当前使用的最大值,可以先这样调整观察

  1. 如果调整后,还是无法满足要求,请尝试添加CPU,或者扩容机器,分散tikv实例

问题已解决,集群恢复正常。采取了以下措施:

  1. 相关表添加 SHARD_ROW_ID_BITS(p.s. 相关表没有主键,TiDB会自动产生自增的隐式主键),使写入热点、以及后续高频计算带来的读热点得以分散
  2. 部署了 @rongyilong-PingCAP 建议的调优参数,CPU消耗得以有效降低,不再成为影响正常吞吐的瓶颈

谢谢!:+1: