同一个查询语句,每次执行时间差异较大

连的同一个tidb server , 每次执行同一个查询语句,响应时间相差比较大,各位大神帮忙看看什么地方遇到了瓶颈

image

------------------------------------------------------------------------------------------

image

--------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------

1赞

辛苦按照 提问须知,提供 tidb 版本,表数据量等相关信息。

总共才一行数据,这上面执行的慢的时候花了 1 秒多钟,集群这段时间是不是比较忙?看看 tidb slow log 中这条 sql 执行时间 1 秒多钟的 log 呢?另外提供一下 select tidb_version() 的结果,看看具体是什么版本的 TiDB

1赞

select tidb_version() 的结果 Release Version: v3.0.2 Git Commit Hash: 94498e7d06a244196bb41c3a05dd4c1f6903099a Git Branch: HEAD UTC Build Time: 2019-08-07 02:35:52 GoVersion: go version go1.12 linux/amd64 Race Enabled: false TiKV Min Version: 2.1.0-alpha.1-ff3dd160846b7d1aed9079c389fc188f7f5ea13e Check Table Before Drop: false

看看 tidb slow log 中这条 sql 执行时间 1 秒多钟的 log 呢?

slow log 日志调整为3秒以上记录了,这个1秒多的没记录

可以调整下 slow log 的阈值,能抓到这类语句的具体执行信息(比如 1s),方便分析问题。

这个和最近MT的问题是不是一个原因啊?

你的 duration 耗时太高了,可以先看看 TiKV metrics 面板里面的 gRPC duration,如果耗时也很高,那就是 TiKV 有瓶颈,如果不高,那就是 TiDB 太忙了。

旧版本过多,往往是 gc 不及时。关于 gc 的配置可以查看:https://pingcap.com/docs-cn/v3.0/reference/garbage-collection/configuration/。其中比较重要的几个参数: tikv_gc_run_intervaltikv_gc_life_timetikv_gc_concurrency

1赞

旧版本过多,往往是 gc 不及时。关于 gc 的配置可以查看:https://pingcap.com/docs-cn/v3.0/reference/garbage-collection/configuration/。其中比较重要的几个参数: tikv_gc_run_intervaltikv_gc_life_timetikv_gc_concurrency

gc的时间与内存消耗有关系吗

GC 主要是针对因为 Drop,Truncate table,或者 DML 产生的版本进行清理,原则上不会与内存消耗有直接的关联。版本过多,会影响 sql 的查询效率,并且对 tikv 的内存会产生一定的影响。

如果是因为 GC 不及时,导致慢查询,processed key 和 total key 的数量差异比较大,则建议查看 GC 相关的配置以及 GC 运行的状态。

学习了 @nhai