TiDB 集群 TiKV 节点内存占用较高问题排查
【是否原创】否
【作者】@seiang
【首发渠道链接】http://www.seiang.com/?p=1212
TiDB 集群上线运行一段时间，近期巡检的时候发现一个问题，集群中 TiKV 节点内存占用比较高，尤其在导入数据的时候，节点的内存会更高
下面我们就针对 TiKV 节点高的问题进行分析：
首先确认下 TiKV 节点配置如下：
问题排查
1、登录到单个 TiKV 接节点，查看内存占用情况
2、确认节点的 THP（内存大页）是否关闭
关闭透明大页（即 Transparent Huge Pages，缩写为 THP）。数据库的内存访问模式往往是稀疏的而非连续的。当高阶内存碎片化比较严重时，分配 THP 页面会出现较高的延迟。
从查看结果看，内存大页是关闭的
3、在通过监控 TiKV-Details RockDB 面板确认是否是 block size 引起的，查看每一个 TiKV 节点的 block size 的内存占用都达到了最大设置 10G
调整 block size 大小的配置，建议不超过机器内存的 60%
调整参数，调整大小为 7G，storage.block-cache.capacity: 7GB
调整完成之后，重启 TiKV 节点
重启完成后，查看内存占用情况
拓展
TiKV 的配置参数：
storage.block-cache 表示 RocksDB 多个 CF 之间共享 block cache 的配置选项。当开启时，为每个 CF 单独配置的 block cache 将无效。
shared
是否开启共享 block cache。
默认值：true
capacity
共享 block cache 的大小。
默认值：系统总内存大小的 45%
单位：KB|MB|GB
为了提高读取性能以及减少对磁盘的读取，RocksDB 将存储在磁盘上的文件都按照一定大小切分成 block（默认是 64KB），读取 block 时先去内存中的 BlockCache 中查看该块数据是否存在，存在的话则可以直接从内存中读取而不必访问磁盘，可以理解为 MySQL 中的 innodb buffer pool。
BlockCache 按照 LRU 算法淘汰低频访问的数据，TiKV 默认将系统总内存大小的 45% 用于 BlockCache，用户也可以自行修改 storage.block-cache.capacity 配置设置为合适的值，但是不建议超过系统总内存的 60%。
写入 RocksDB 中的数据会写入 MemTable，当一个 MemTable 的大小超过 128MB 时，会切换到一个新的 MemTable 来提供写入。TiKV 中一共有 2 个 RocksDB 实例，合计 4 个 ColumnFamily，每个 ColumnFamily 的单个 MemTable 大小限制是 128MB，最多允许 5 个 MemTable 存在，否则会阻塞前台写入，因此这部分占用的内存最多为 4 x 5 x 128MB = 2.5GB。这部分占用内存较少，不建议用户自行更改。
也欢迎大家关注作者的个人微信公众号：
TiDB 社区官网:https://tidb.net/ 2021.12.15 加入
TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目，旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/
评论