tidb重启

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】
【概述】场景+问题概述
tidb经常重启,日志中找不到oom的SQL,从监控上看内存也没有OOM的迹象
【背景】做过哪些操作
【现象】业务和数据库现象
【业务影响】
【TiDB 版本】
V4.0.9
【附件】

  1. TiUP Cluster Display 信息

  2. TiUP Cluster Edit Config 信息

  3. TiDB- Overview 监控
    image

  • 对应模块日志(包含问题前后1小时日志)

vi tidb.log

[2021/09/22 07:00:26.153 +08:00] [INFO] [printer.go:33] [“Welcome to TiDB.”] [“Release Version”=v4.0.9] [Edition=Community] [“Git Commit Hash”=69f05ea55e8409152a7721b2dd8822af011355ea] [“Git Branch”=heads/refs/tags/v4.0.9] [“UTC Build Time”=“2020-12-21 04:26:49”] [GoVersion=go1.13] [“Race Enabled”=false] [“Check Table Before Drop”=false] [“TiKV Min Version”=v3.0.0-60965b006877ca7234adaced7890d7b029ed1306]

vi tidb_stderr.log

goroutine 1017919 [select, 97 minutes]:
google.golang.org/grpc/internal/transport.(*controlBuffer).get(0xc002bb19a0, 0x1, 0x0, 0x0, 0x0, 0x0)
/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/pkg/mod/google.golang.org/grpc@v1.26.0/internal/transport/controlbuf.go:395 +0x122
google.golang.org/grpc/internal/transport.(*loopyWriter).run(0xc005a554a0, 0x0, 0x0)
/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/pkg/mod/google.golang.org/grpc@v1.26.0/internal/transport/controlbuf.go:513 +0x1e3
google.golang.org/grpc/internal/transport.newHTTP2Client.func3(0xc000173180)
/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/pkg/mod/google.golang.org/grpc@v1.26.0/internal/transport/http2_client.go:346 +0x7b
created by google.golang.org/grpc/internal/transport.newHTTP2Client
/home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/pkg/mod/google.golang.org/grpc@v1.26.0/internal/transport/http2_client.go:344 +0xedb

哪个时间点重启的? 这个时间周期内的日志和监控都没有异常么?

看一下操作系统日志有没有tidb-server被杀掉的记录,看具体是什么原因

早上7点时,内存使用为0,看上图

是这个原因,日志如下:Killed process 16602 (tidb-server) total-vm

tidb 被 linux 当过载应用,直接给 kill 了,限制一下 tidb 的最大内存…

参考下这个文档:
https://docs.pingcap.com/zh/tidb/stable/configure-memory-usage

最好升级到 4.0.14这个版本,知乎也是推荐这个版本

mem-quota-query配置的是2G,没啥用

如果有 100 个 Query,同时发起查询请求,刚好你设定的 每个查询最大是 2G,100 * 2 G ,如果是慢查询执行时间过久,内存不足,可能就 OOM了

可以考虑下最大执行时间 和 缩小每个Query 允许的内存

另外,能升级就先升级,升级后在观察看看

好的,目前最的问题是引起OOM的SQL没找到,OOM后服务马会被杀,连挣扎的机会都没有

可以关注一下 慢SQL,通过查询 内存占用较大的 SQL ,先优化一波

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。