- 【TiDB 版本】：5.7.25-TiDB-v4.0.2
- 【问题描述】：TiDB节点涉及到几个大的查询SQL一起执行，就会导致内存溢出，节点宕机重启，这个有什么配置参数可以控制资源消耗，做排队处理吗？
参考文档设定内存阈值，如果 sql 超过一定阈值 cancel，业务可以设定重试，这样可能可以避免。 或者，业务上尽量避免多个大sql同时运行。
https://docs.pingcap.com/zh/tidb/stable/configure-memory-usage#tidb-内存控制文档
还是有这个问题，设置阈值+重试并不能解决问题，sql还是占用那么多资源，重试后TIDB节点还是会挂掉。
类似于insert select语句，看现象像是tidb节点会加载所有select需要的数据，如果数据量内存消耗过大， 就会宕掉
这个当前有什么机制，后者后续版本会有优化手段吗，比如流式处理
可以处理慢点，但是不让节点挂掉
- 如果是需要全部数据到内存，目前看起来考虑增大硬件内存
- 如果 sql 中是一些临时group by中间数据导致内存大，可以配置tmp-storage-path
https://docs.pingcap.com/zh/tidb/stable/tidb-configuration-file#tmp-storage-path
我不清楚TiDB是如何做资源调度的，我觉得问题核心是有大sql或者多个sql消耗资源大于机器资源时，可以接受执行的慢一些，但是无法接受节点宕机重启
我记得3.x版本使用时，当sql操作比较多时，会明显感受到系统变慢，但是并没有频繁的宕机重启
当前的方案并不能解决宕机的问题，因为都是sql层面的控制，并不是全局的资源控制
比如我们不能因为存在2个消耗100G的sql，就一定要上256G的内存，128G内存也能执行，主要是资源调度策略
4.0 中增加了 tmp-storage-path 以及 tmp-storage-quota 参数，当单个 SQL 执行使用的内存超过 mem-quota-querey 的限制的时候，会将某些算子从内存中落到磁盘临时文件，牺牲执行效率。
我知道有这个配置参数，我的问题不是这个，因为我们内部TiDB是作为数仓存储使用，有很多大sql查询
比如：TiDB节点是64G内存服务器
1.如果配置mem-quota-query参数为10GB，那么6个消耗10GB的SQL就会把节点跑挂重启
2.如果设置为5GB，某个时间点可能只有一个消耗20GB的SQL在执行，并没有充分利用空闲时的资源
这里还涉及到GC是否能够及时的回收内存
通过之前的沟通，TiDB当前应该是不支持更灵活的资源调度（例如Yarn）的，这块未来路线图有资源调度相关的计划吗
暂时应该没有，您可以把好的建议或者其他数据库上的特性，整理为需求提到 github tidb 下，辛苦了，多谢。
好的好的，多谢解答
兄弟，你这个问题有没有解决
额，资源不够直接crash宕机处理也太粗暴了
crash直接满了，导致我这边部署的其他服务都重启不了
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。