当前,tidb 一条慢SQL会导致整个集群性能急剧下降

当前sql直接好像没有做好资源隔离,导致一个慢sql查询占用了所有的kv资源,使得其他的数据库操作受到资源影响。
在mysql中,有参数innodb_concurrency_tickets限制一次CPU时间获取5000条记录,然后执行其他SQL,这样就不会有一条SQL执行其他SQL都被拖慢的情况。
tidb是不是也应该要做类似的功能,否则一旦线上出现了一两次慢查询,整个集群都收到很大的影响。

tidb现在是会拖累整个集群


可以看下

测试环境可以先跑下,你也可以搜索下其他人遇到的问题
image
了解下大致的情况~

慢sql排查是一方面,要尽量避免。但是当前这种情况,只要出现一次慢查询,在慢查询执行期间,整个系统受到大范围影响,这个太苛刻了。

1赞


之前还有疑问,为啥突然出现一批慢写入,从执行计划有看不出耗时在哪里,现在看起来,应该是那段时间有个慢查询阻塞了。

MAX_EXECUTION_TIME 参数或hint可以限制一个SQL的最大执行时间,超过了会被杀掉。

试试把长时间执行的语句加上LOW_PRIORITY 能降低影响不

慢SQL会拖垮整个tidb集群的

定义sql为high priority,是表示它会进入storage read pool或unified read pool的high区呢?

这种就靠限制资源使用,还有超时机制来搞定,上线前的SQL审计

我的意思不是单独解决这一个sql的问题。是不同sql要做资源隔离的设计,按照当前的设计,手动执行一条复杂查询,就能把数据库拖死。
我认为这是一个很大的缺陷,官方要出方案去解决这个问题,类似mysql之类的解决方案,不能让大的事务长期占用所有的系统资源。希望能在后续版本中看到它的改善

我理解,例如内存的限制:
image
跟你说的限制类似么?
还有https://pingcap.com/zh/blog/unified-thread-pool
这是类似加入了优先级和类时间片轮转方案,目前已经在tikv中包含了。

这的确是个值得关注的问题

任何数据库都怕低效SQL。有点一个就可以让数据库资源耗尽。
所以在大厂,上线前要审核,就是这个道理。

oracle数据库都不一定能抗住一个烂SQL,mysql虽说有这机制 照样扛不住, tidb有调整tikv并发的一些相关参数比如tidb_distsql_scan_concurrency、index_lookup_concurrency等,评估有影响的大SQL可以降低这些参数值。另外你的集群配置什么样?什么样的SQL把集群拖垮了,可发出来看看

1赞

一条sql 执行过慢 可能有多中原因造成的,如果tidb自动对sql的进行限流或限速,给其他sql让路
那么重要的业务sql异常 将无法第一时间知道和分析。需要做一个平衡。

个人觉得这个问题目前可以通过sql审计,超时机制来设置