tikv内存不断上涨超过storage.block-cache.capacity设置的值

【 TiDB 使用环境】测试
【 TiDB 版本】7.5.3
【复现路径】做过哪些操作出现的问题
系统部署好后,就放着,周末没有其他操作
【遇到的问题:问题现象及影响】
系统放置一个周末后过来查看tikv 的内存不断上涨,达到了17G左右


此期间整套系统并没有其他测试任务或操作

操作系统为UOS的arm系统

THP已关闭
image

TiKV配置如下

# TiKV config template
#  Human-readable big numbers:
#   File size(based on byte): KB, MB, GB, TB, PB
#    e.g.: 1_048_576 = "1MB"
#   Time(based on ms): ms, s, m, h
#    e.g.: 78_000 = "1.3m"

log-level = "info"
log-rotation-size = "30MB"
log-rotation-timespan = "1h"

[readpool]

[readpool.coprocessor]
high-concurrency = 64
low-concurrency = 64
normal-concurrency = 32
use-unified-pool = true

[readpool.storage]
normal-concurrency = 10
use-unified-pool = true

[readpool.unified]
auto-adjust-pool-size = true

[pessimistic-txn]
enabled = true
pipelined = true


[server]
grpc-concurrency = 16
grpc-raft-conn-num = 16

[storage]

[storage.block-cache]
capacity = "13043MB"
shared = true

[pd]
# This section will be overwritten by command line parameters

[metric]

[raftstore]
apply-max-batch-size = 1024
raftdb-path = ""
store-max-batch-size = 1024

[coprocessor]

[rocksdb]
max-background-flushes = 4
max-background-jobs = 16
use-direct-io-for-flush-and-compaction = true
wal-bytes-per-sync = 128

[rocksdb.defaultcf]
compression-per-level = ["lz4", "lz4", "lz4", "lz4", "zstd", "zstd", "zstd"]
level0-slowdown-writes-trigger = 64
level0-stop-writes-trigger = 64

[rocksdb.lockcf]
level0-slowdown-writes-trigger = 64
level0-stop-writes-trigger = 64

[rocksdb.writecf]
compression-per-level = ["lz4", "lz4", "lz4", "lz4", "zstd", "zstd", "zstd"]
level0-slowdown-writes-trigger = 64
level0-stop-writes-trigger = 64

[raftdb]
use-direct-io-for-flush-and-compaction = true

[raftdb.defaultcf]
compression-per-level = ["lz4", "lz4", "lz4", "lz4", "zstd", "zstd", "zstd"]

[security]

数据目录大小 9G
image

看之前的帖子arm内存高主要是 THP 导致的, 但是已经关闭了,当前几个升级了tidb7.5.3 版本的测试环境 tikv 内存占用都挺高 ,不清楚是不是有什么参数要修改之类的, 各位大佬有没有什么建议的排查方向, 或者有没有对应的经验分享一下。 本人对tidb 还不是很熟悉,不知道该怎么排查了

【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件:截图/日志/监控】

storage.block-cache.capacity设置的值并不是你的tikv内存占用的极限,这个值应该设置为你机器内存的45%左右,这个只是数据缓存的大小,tikv最大能占用到这个值的2.25倍。

1 个赞

没有操作,内存也在一直涨?

没有人为去操作,但是系统是在运行的,会有一些系统里各个服务的一些sql操作

一开始我也觉得是正常的,但是我的数据量其实很少,内存却占了17G, 远远超过了我的数据量,才开始觉得是不是哪里有问题

capacity = “13043MB”,这个可以再调小一点看看(可以在线改)
SET config tikv storage.block-cache.capacity=‘8G’

超过 block-cache 设置是预期的,参考官方文档 TiKV 实例使用 5/3 * block-cache.capacity 的内存。https://docs.pingcap.com/zh/tidb/stable/tikv-configuration-file#memory-usage-limit

1 个赞

按照这个配置在预留50%的buffer吧

还有个疑惑点就是 tidb 4.0.12版本的不会一直上涨 但是 tidb 7.5.3版本的却会,就感觉很奇怪 是不是 新版本引入了什么或者新版本需要添加一些新的配置
image

v6, v7这些版本我也测试了,也都会上涨,最开始以为是gc导致的,发现还不是,最后通过top -H看tikv的进程发现,很多组件占用的内存确实也很多

memory-usage-limit

  • TiKV 实例的内存使用限制。当 TiKV 的内存使用量接近此阈值时,内部缓存会被清除以释放内存。
  • 在大多数情况下,TiKV 实例被设置为占系统可用总内存的 75%,因此你不需要显式指定此配置项。剩余 25% 的内存用于操作系统的页缓存,详情参见 storage.block-cache.capacity
  • 在单个物理机上部署多个 TiKV 节点时,你也不需要设置此配置项。在这种情况下,TiKV 实例使用 5/3 * block-cache.capacity 的内存。
  • 不同系统内存容量的默认值如下:
    • system=8G block-cache=3.6G memory-usage-limit=6G page-cache=2G
    • system=16G block-cache=7.2G memory-usage-limit=12G page-cache=4G
    • system=32G block-cache=14.4G memory-usage-limit=24G page-cache=8G

看下你的 memory-usage-limit参数的值是多少,看官方文档是说:TiKV 实例的内存使用限制。当 TiKV 的内存使用量接近此阈值时,内部缓存会被清除以释放内存,原文连接: TiKV 配置文件描述 | TiDB 文档中心 (pingcap.com)

tikv使用的内存不只是block-cache,

详见8.2 TiKV 常见配置优化 | tidb-in-action

1 个赞

内存是tikv进程一直占用着吧,然后一直到达一个平衡

这个看上去像是总内存

但是,我的数据只要7万多条 数据目录也才9g , 但是tikv内存却占了 18G 远远大于此前的 4.0.12版本 就感觉哪里没配置好 4.0.12版本 才用 几G

对,我现在比较迷惑的点是 7.5.3 版本 相比于 4.0.12 版本内存占用高了太多,对我们当前入驻式的部署方式 会有较大影响

可以收个 profile 发出来看下
收集方式如下:

  1. 开启heap收集,执行命令后等待2分钟

curl http://:<status_port>/debug/pprof/heap_activate?interval=60

  1. 查看收集结果 curl http://:<status_port>/debug/pprof/heap_list

  2. 将第二步中收集结果拷贝出来

  3. 关闭heap收集 curl http://:<status_port>/debug/pprof/heap_deactivate jeprof --svg <prof.heap> > out.svg

1 个赞

7.5版本比4.0版本也增加了很多特性,我感觉内存占用多其实也比较正常