cf size write占用内存空间不断上升

[Lystorm]

【 TiDB 使用环境】
V5.4

【概述】 计算程序周期性运行，不断处理数据，系统内存的buffer空间占用越来越高，监控下发现CF size的write模块占用空间一直在上升

【背景】 限制storage.block.cache大小为5G,共三个TIKV节点，修改配置文件后重启tikv

【现象】 CF size仍旧持续上升

[ddhe9527 (多多)]

write CF size占用的不是内存空间，是磁盘空间。随着你写入TiDB的数据量的增长，default cf和write cf都会随之增长

[Lystorm]

default cf和write cf都是占用磁盘，不是内存么？

[ddhe9527 (多多)]

内存中是BlockCache和每个CF的memtable，参考下面文档
https://docs.pingcap.com/zh/tidb/stable/rocksdb-overview#rocksdb-的内存占用

CF指的是RocksDB中的Column Family，它是由磁盘上的SST文件组成的

[Lystorm]

那么在不修改memtable和memtable最大文件数的前提下，单个TIKV节点的内存，应该等于storage.block.cache+2.5G。那我的这个环境，单TIKV的内存占用应该是在7.5G左右。
但是实际我发现单个TIKV的内存占用，会到8G甚至更多，除了这两块，还有别的比较吃内存的模块么？

[ddhe9527 (多多)]

https://docs.pingcap.com/zh/tidb/stable/tune-tikv-memory-performance#tikv-内存使用情况

[Lystorm]

TIKV的数据返回给TIDB Server的时候，是数据全部处理完毕了一次性返回，还是异步的形式，一点一点的返回呢？

[yilong (yi888long)]

你说的应该是大批量比如select * from xxx 返回几万条数据。批量返回的。
https://pingcap.com/zh/blog/tikv-source-code-reading-14

[ddhe9527 (多多)]

它是边写边发的，coprocessor不断往内存中写，gRPC从内存中读取并发送给TiDB实例。如果coprocessor写的速度比gRPC发送的速度快，那内存中就会堆积起来