【 TiDB 使用环境】测试单机模拟集群
【 TiDB 版本】
【复现路径】
【遇到的问题：问题现象及影响】
用datax采集单表数据到tidb，测试5000w数据的时候会因为capacity的设置太大会出现OOM，所以我后面控制在三千多w数据能正常采集完成，数据采集完成后，每个tikv所占内存都到了8g左右，到第二天也一直不会释放，查看tikv的日志也没有内存回收的错误，如果我还要继续采集其他表数据就必须重启tikv，请问采集完成后这个内存为啥会一直不降下来，在采集数据的时候内存是用在哪，什么时候会释放？
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
只要设置storage.block-cache.capacity的值设置合理就行，tikv缓存的数据也会被最新的数据刷出去的。。。
但是你这个资源也太紧张了，建议不如直接用单机mysql。。。
1 个赞
他这个是测试单机模拟集群的。但是如果测试性能，还是应该用集群呀，单机反映不了真实性能。
OOM了说明你的TIKV内存使用限制值应该超过了你的最大内存，数据使用了肯定是会在缓存里存着的
单机模拟集群，如果没有改storage.block-cache.capacity这个值的话，3个TIKV节点每个节点的默认都是用45%的内存，在单机里肯定就OOM了
你说的对 
tikv不会释放的，你设置capacity后有个最大值,tikv控制一般不超过最大值，但是不会再释放缓存的数据了
不是释放内存的部分主要是rocksdb的block cache。
lsmtree这种数据结构对写友好，把随机写变成了顺序写。
但是对读不友好，特别是范围扫描，可能需要扫面很多层，造成读放大。
block cache的存在就是为了平衡读写之间的性能。
部署坏境来说，内存的表现正常。内存不释放。可以通过其他方式。
sync;sync;sync #写入硬盘，防止数据丢失
sleep 20
echo 1 > /proc/sys/vm/drop_caches
echo 2 > /proc/sys/vm/drop_caches
echo 3 > /proc/sys/vm/drop_caches
这样应该可以
那就算是非单机模拟集群部署，当采集的数据量更大时，tikv岂不是也会占满，沾满后不也会影响服务么？
不会满，会有个上限，安装时候按主机内存评估的。混合部署时候如果按tikv独立部署占用内存，自然是不够的，需要手工改参数
page cache是关闭的，我每个tikv设置成capacity=6g后，把剩余的3000多w数据采集完了，每个tikv确实没超过6g，但是今天不知道时给个大表加索引还是增量数据 同步数据造成tikv的内存又到了9g，服务器死机了，最后索引也没加上，重启集群也释放不掉，不知道这个内存是被啥消耗了
capacity=6上限差不多就是9，这个只是缓存配置