5.4OOM问题频发,新版本有没有这方面的优化

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】V5.4
物理内存250G,tikv限制内存90G,实际使用超出了限制,导致OOM

tikv OOM 还是 tidb OOM?能看下集群部署架构吗?

TiKV 的内存占用主要来自于 RocksDB 的 block-cache,默认为系统总内存的 40%。当 TiKV 容易出现 OOM 时,检查 block-cache-size 配置是否过高。还需要注意,当单机部署了多个 TiKV 实例时,需要显式地配置该参数,以防止多个实例占用过多系统内存导致 OOM。

Cluster type: tidb
Cluster name: xxxxx
Cluster version: v5.4.1
Deploy user: tidb
SSH type: builtin
Dashboard URL: http://xxx.xxx.xx.56:2379/dashboard
ID Role Host Ports OS/Arch Status


xxx.xxx.xx.54:2379 pd xxx.xxx.xx.54 2379/2380 linux/x86_64 Up
xxx.xxx.xx.56:2379 pd xxx.xxx.xx.56 2379/2380 linux/x86_64 Up|UI
xxx.xxx.xx.57:2379 pd xxx.xxx.xx.57 2379/2380 linux/x86_64 Up
xxx.xxx.xx.58:2379 pd xxx.xxx.xx.58 2379/2380 linux/x86_64 Up|L
xxx.xxx.xx.59:2379 pd xxx.xxx.xx.59 2379/2380 linux/x86_64 Up
xxx.xxx.xx.54:3306 tidb xxx.xxx.xx.54 3306/10080 linux/x86_64 Up
xxx.xxx.xx.56:3306 tidb xxx.xxx.xx.56 3306/10080 linux/x86_64 Up
xxx.xxx.xx.58:3306 tidb xxx.xxx.xx.58 3306/10080 linux/x86_64 Up
xxx.xxx.xx.59:3306 tidb xxx.xxx.xx.59 3306/10080 linux/x86_64 Up
xxx.xxx.xx.60:3306 tidb xxx.xxx.xx.60 3306/10080 linux/x86_64 Up
xxx.xxx.xx.61:3306 tidb xxx.xxx.xx.61 3306/10080 linux/x86_64 Up
xxx.xxx.xx.54:5660 tikv xxx.xxx.xx.54 5660/5680 linux/x86_64 Up
xxx.xxx.xx.54:5661 tikv xxx.xxx.xx.54 5661/5681 linux/x86_64 Up
xxx.xxx.xx.56:5660 tikv xxx.xxx.xx.56 5660/5680 linux/x86_64 Up
xxx.xxx.xx.56:5661 tikv xxx.xxx.xx.56 5661/5681 linux/x86_64 Up
xxx.xxx.xx.57:5660 tikv xxx.xxx.xx.57 5660/5680 linux/x86_64 Up
xxx.xxx.xx.57:5661 tikv xxx.xxx.xx.57 5661/5681 linux/x86_64 Up
xxx.xxx.xx.58:5660 tikv xxx.xxx.xx.58 5660/5680 linux/x86_64 Up
xxx.xxx.xx.58:5661 tikv xxx.xxx.xx.58 5661/5681 linux/x86_64 Up
xxx.xxx.xx.59:5660 tikv xxx.xxx.xx.59 5660/5680 linux/x86_64 Up
xxx.xxx.xx.59:5661 tikv xxx.xxx.xx.59 5661/5681 linux/x86_64 Up
xxx.xxx.xx.60:5660 tikv xxx.xxx.xx.60 5660/5680 linux/x86_64 Up
xxx.xxx.xx.61:5660 tikv xxx.xxx.xx.61 5660/5680 linux/x86_64 Up
Total nodes: 23

挂掉是60和61,系统日志,显示:
kernel: Node 0 Normal free:44656kB min:44448kB low:55560kB high:66672kB active_anon:127922900kB inactive_anon:62540kB active_file:856kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:132120576kB managed:130008920kB mlocked:0kB dirty:604kB writeback:416kB mapped:8228kB shmem:205456kB slab_reclaimable:666832kB slab_unreclaimable:68028kB kernel_stack:7584kB pagetables:470320kB unstable:0kB bounce:0kB free_pcp:1604kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:576 all_unreclaimable? no

这个参数配置了,限制90G,物理内存是250G,挂掉的tikv上只有一个tikv节点

这是tidb和tikv共用了?
是tidb内存占用太多导致的oom吧,tikv一般不会oom的

减点再试试。oom时有啥在跑不


网上搜了一个oom算法的图,参考下。

6.5以后的版本会少很多

能看一下这两台机器对应的 grafana的监控图吗?就 tidb、tikv mem usage的那个面板。为什么你这个挂的会是 tikv,混合部署,你限制了 kv 的内存之后,一般不会超过这个 范围,要挂也是挂 tidb

TIDB:

TIKV:

能看一下 tikv OOM 时间点前后的日志吗?你是设置了block-cache-size参数的,为啥你的 tikv 还能用到 110G左右的内存,能检查下参数设置的值吗?

1710489536749

60、61这两台机器上除了部署 tidb 、 tikv 就没部署其余的是吧。能看看这两个机器的配置吗?

再就是看看 tikv 的启动日志,日志里面关于重启的 welcome to tikv 那行的前后 20条,我感觉你这个参数没生效,是写在 tiup 配置文件里面配置的吗?

没有其它的了

启动日志在哪找,历史日志没了

我们还有大版本为4.x的版本

不会吧,tikv.log ,这个文件没了吗?