tiflash OOM 重启

🪐 TiDB 技术问题
1

一个好的问题描述有利于社区小伙伴更快帮你定位到问题，高效解决你的问题

【TiDB 使用环境】生产环境
【TiDB 版本】 v7.5.6
【部署方式】机器部署
【操作系统/CPU 架构/芯片详情】centos7.9
【机器部署详情】40C 128G
【集群数据量】
【集群节点数】6 server + 10 tikv + 5 tiflash
【问题复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
应用日志报错，tiflash 重启
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
查看 tiflash 日志：
[err=“other error for mpp stream: Code: 0, e.displayText() = DB::Exception: Receiver state: ERROR, error message: Exchange receiver meet error : Code: 0, e.displayText() = DB::TiFlashException: Memory limit (total) exceeded caused by ‘out of memory quota for data computing’ : would use 100.29 GiB for data computing (attempt to allocate chunk of 1179648 bytes), limit of memory for data computing: 100.29 GiB. Memory Usage of Storage: non-query: peak=15.53 GiB, amount=3.23 MiB; query-storage-task: peak=2.02 GiB, amount=401.08 MiB; fetch-pages: peak=0.00 B, amount=0.00 B; shared-column-data: peak=2.02 GiB, amount=401.08 MiB., e.what() = DB::TiFlashException, e.what() = DB::Exception,\ngithub.com/pingcap/tidb/pkg/executor/internal/mpp.(*localMppCoordinator).handleMPPStreamResponse\n\t/workspace/source/tidb/pkg/executor/internal/mpp/local_mpp_coordinator.go:634\ngithub.com/pingcap/tidb/pkg/executor/internal/mpp.(*localMppCoordinator).receiveResults\n\t/workspace/source/tidb/pkg/executor/internal/mpp/local_mpp_coordinator.go:510\ngithub.com/pingcap/tidb/pkg/executor/internal/mpp.(*localMppCoordinator).handleDispatchReq\n\t/workspace/source/tidb/pkg/executor/internal/mpp/local_mpp_coordinator.go:463\ngithub.com/pingcap/tidb/pkg/executor/internal/mpp.(*localMppCoordinator).dispatchAll.func2\n\t/workspace/source/tidb/pkg/executor/internal/mpp/local_mpp_coordinator.go:368\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1650”]
【其他附件：截图/日志/监控】
实际当时的内存使用率截图：

image
image1858×499 16.9 KB

image
image663×312 9.69 KB

2

从日志看像是 查询计算内存配额打满了，你可以看下 max_memory_usage_for_all_queries 配置的是多少。再从慢日志查下当时有没有内存消耗较大且走 tiflash 的 sql。

3

max_memory_usage_for_all_queries 这个参数怎么查询，通过 cluster_config 没有查询到；问题发生的时间段没有发现很占用内存的SQL，最大一个SQL内存使用40M

4

有重启前后几十秒的 TiFlash 日志和系统 OOM 日志吗，正常情况下触发这个限制应该是终止相关的查询并返回 OOM，而不是直接把 TiFlash 进程重启，检查下 systemctl status tiflash 以及 dmesg 看有没有进程崩溃或者被 Linux OOM Killer 杀掉

5

看日志是典型的TiFlash内存超限导致OOM重启，limit of memory for data computing: 100.29 GiB 说明计算内存配额被打满。

建议按以下顺序排查：

  1. 调大TiFlash内存配额（临时缓解）：在tiflash.toml中调整max_memory_usage和max_memory_usage_for_all_queries，比如从默认值调到110-120G，注意留出系统余量，128G机器建议上限120G。
6

更正一下，现在确认tiflash 的重启跟这个没关系，是人为手动重启的，OS层没有OOM记录；21:37左右 tiflash.log 刷了很多这种 out of memory quota for data computing 报错，但从监控查看服务器实际已使用内存并不高，这种是什么原因呢，内存泄漏了吗？

7

日志是 TiFlash 计算内存打到上限后 OOM。先降 MPP 并发和单查询扫描范围，避免超大 join/聚合打到 TiFlash。可调 TiFlash 内存相关配额，并把过重的 AP 拆批或加过滤。重启只是止血，不改查询和并发还会再炸。

8

TiFlash 发生 MPP 查询 OOM 重启，日志显示 data computing 需要占用约 100G 内存，128G 机器内存不足以支撑该大查询。可以优化 SQL、临时关闭 MPP，开启算子 spill 落盘；也可调整 tiflash 内存参数，必要时扩容 TiFlash 内存规格。

9
max_memory_usage_for_all_queries
  • 所有查询过程中，节点对中间数据的内存限制。
  • 设置为整数时，单位为 byte，例如 34359738368 表示 32 GiB 的内存限制，0 表示无限制。
  • 从 v6.6.0 开始，支持设置为 [0.0, 1.0) 之间的浮点数，表示节点总内存的比值。例如，0.8 表示总内存的 80%，0.0 表示无限制。
  • 当查询试图申请超过限制的内存时，查询终止执行并且报错。
  • 默认值：0.8，表示总内存的 80%。在 v6.6.0 之前，默认值为 0，表示不限制。

没有显示配置的话就是总内存*0.8

10

问题解决了吗楼主

11

测试环境暂时没能复现问题

12

调整这个参数 max_memory_usage_for_all_queries，在观察一段时间看看