【 TiDB 使用环境】生产环境
【 TiDB 版本】7.5.1
下图,18分,23分奔溃了。
TIFLASH经常被查到奔溃, 看日志不好定位哪个sql引起的,靠猜。有什么排查思路么?
logs-tiflash_172.17.64.178_3930.zip (166.4 KB)
【 TiDB 使用环境】生产环境
【 TiDB 版本】7.5.1
下图,18分,23分奔溃了。
TIFLASH经常被查到奔溃, 看日志不好定位哪个sql引起的,靠猜。有什么排查思路么?
先在慢SQL里找一下,看其执行计划有没有下推到TIFLASH
不知道这个log里面会不会一样记录expensive sql,如果记录可以查一下。
https://docs.pingcap.com/zh/tidb/stable/tiflash-spill-disk#查询级别的落盘
7.4开始tiflash支持查询级的落盘。可以打开这个功能,看看能否不发生oom直到跑完。
只要不是瞬间tiflash oom应该在慢查询里面都能找到。
分析慢sql,然后看是否下推到了tikv
扩内存
请问查询尚未结束的SQL是否会记录到慢日志?
集群组件是如何部署的?
不会,只有执行成功的才会
mark,学一下如何排查
有没有可能是执行计划走偏了,原本应该是用tikv查的多列数据,现在用tiflash查了
从慢SQL找找,再结合执行计划来看看。
看一下s q l
不会记录,一般慢查询排查的时候,如果是实时慢,一般都是cluster_processlist + 慢日志一起看,一个是正在执行,一个是执行完成