【 TiDB 使用环境】生产环境
【 TiDB 版本】v6.5.1
【遇到的问题：问题现象及影响】
有半个小时左右的时间，涉及tiflash的查询都变的很慢，似乎hang住了，看主机负载又没有很高，后来又自动恢复正常。
【附件：截图/日志/监控】
从监控看tiflash似乎hang住了
查询时间从几秒攀升到几分钟
日志中的warning是平时就有存在的，没有新的特殊的错误日志
不知道这问题该如何排查？
查询时间从几秒攀升到几分钟
不知道这问题该如何排查？
看下两个tiflash节点在对应时间点的cpu使用情况，就在summary界面看下就行，另外看下coprocessor
下的Threads of Rpc这个监控截图
tiflash机器上cpu128核？看你用了大概用了50核的样子，看着tiflash的负载确实不算高， tidb_max_tiflash_threads这个SHOW GLOBAL VARIABLES LIKE '%tidb_max_tiflash_threads%'看下设置是-1吗，当时是仅仅tiflash类的请求慢吗？你看下没有用tiflash的sql是不是也很慢
对应时间点garafana监控里面overview→tidb→KV Backoff OPS，这里看下有rpc异常重试吗？
你的regionmiss很高但是问题点出现之前也有这情况，这个可能就是你的集群写入并发量太大了，reigon一直在分裂调度，导致tidb-server从pd获取的region信息报错而重试。感觉你的tikv应该很忙啊，但是你问题点的时候tikv又没问题。。。。你看下tidb的日志，在对应时间点有报错吗？
有那些应该访问tiflash的SQL的完整执行计划吗
好长，期间有没有analyze
你这执行计划全是pseudo关键字啊，要不先把表的统计信息收集下呢。。。。
期间没有analyze
收集了执行计划还是有pseudo字眼，执行计划和平时快的时候差不多，这个分区表全表就3000多万数据，也不算太大。
个人猜测 1.Tiflash是fork ClickHouse开发的虽然没有直接沿用LSMTree存储引擎 而是重写了更适合HTAP 场景的列存引擎DeltaTree 但是类比CK 的LSMTree数据Merge过程中会存在数据不可用情况 外在表现就是Hang住了一般
2.Tiflash也是MPP架构 所有MPP都天然有架构上的不足 当数据分布不均衡也就是有数据倾斜时 会导致单节点负载过高 外在表现就是集群变慢 实际上其它节点全部在等待数据倾斜节点作业完成再进行下一步 如果数据倾斜特别严重 还可能导致执行资源被长期占据 而其它作业因拿不到执行资源处理队列等待状态 此时的外在表现则是集群异常缓慢 而实际上是大部分作业处理等待状态根本未执行
如果MPP架构的数据库突然变慢 先从数据倾斜数据分布资源等待等方向去找问题 可能更容易找到问题原因 以上个人愚见望有所助益
1 个赞
只有两个tiflash节点，tiflash两副本，数据没有明显倾斜。在集群变慢时，从主机资源来看反而似乎都空闲下来了。目前只能把所有tiflash表的统计信息健康度低于70的都定时收集下，再跟踪几天看下。
1 个赞
我们也打算这周升到6.5.10，到时候再看下，感谢
1 个赞
现在问题解决了吗？ 从监控看能明显看到 cop 的 request 增加了很多，建议可以从 sql 入手看下对应时间段有没有异常sql大量访问 tiflash 节点