【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】V7.1.1
【遇到的问题：问题现象及影响】tikv组件，服务器内存配置64G，但是dashboard界面显示tikv内存使用了70%左右，想问下这些内存是哪些进程或者sql在占用，以及进程对资源的使用情况，如何排查
TiKV使用内存一般不会很夸张，如果持续时间久，需要排查一下block cache 的配置情况。
同时确认有无混合部署的情况发生，尽量不混合部署。
1 个赞
没有混合部署，都是独立部署。block cache在哪看，作用是什么
TiKV Block-cache用于缓存数据块，加速 RocksDB 的读取速度。Block-cache 的大小通过参数 block-cache-size 控制，block-cache-size 越大，能够缓存的热点数据越多，对读取操作越有利，同时占用的系统内存也会越多。
tikv 内存调优，可以看看官网这篇文章：
https://docs.pingcap.com/zh/tidb/stable/tune-tikv-memory-performance
确认节点的THP（内存大页）是否关闭。数据库的内存访问模式往往是稀疏的而非连续的，当高阶内存碎片化比较严重时，分配THP页面会出现较高的延迟。可以通过以下命令查看THP状态：
cat /sys/kernel/mm/transparent_hugepage/enabled，如果结果为always madvise [never] ，则表示THP已关闭。另外，通过监控TiKV-Details RockDB面板确认是否是block size引起的内存占用问题。如果block size的内存占用达到了最大设置值，可以考虑调整block size大小的配置，建议不超过机器内存的60%
tikv 内存会用到这些块： Region 内存
10k region 大约消耗 500MB 内存
rocksdb
block cache ：默认值为 TiKV 默认将系统总内存大小的 45% storage.block-cache.capacity
memtable ( tikv details / rocksdb kv / memtable size)
raftstore
raftstore memtrace ( tikv details / server / memory trace → raftstore)
memory fragmentation (tikv details / memory / allocator stats → fragmentation and dirty and meta )
resolved-ts
lock heap size =0 (tikv details / resolved-ts / lock heap size) 其内存来源为每行记录 apply 后的 track 填充。
TiKV 无负载下启动常驻 =~ 1.3G
Task
Unified Read Pool
普罗米修斯监控tikv方面的信息，应该可以
部署的时候都没有配置该参数
部署集群时已关闭THP，但是tikv组件只是设置一些简单参数，相关调优参数没设置
具体哪些呢
我没有设置block cache参数，如果按你说的，默认内存占用应该不超过45%，现在为什么达到60%多呢
从 v5.4 起，默认启用raft-engine。内存占用计算方式如下：
占用内存=block-cache.capacity (默认值：系统总内存 * 45%)+ ( write-buffer-size * max-write-buffer-number * 4 ) + raft-engine.memory-limit(默认值：系统总内存 * 15%)
你是多 kv 部署吗
是的，多个节点
好的，谢谢。主要是现在tikv组件占用内存较多，不知道后续会不会持续上升
多 KV 节点就是符合预期的
多个节点需要设置tikv的blockcache，2个tikv，每个tikv，20%内存，如果有其他混部组件，可以进一步缩小。比如15%，10%等。
通过TOP - H看下