为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。
- 【TiDB 版本】：4.0.6
- 【问题描述】：从grafana界面看内存使用率，发现tikv节点的内存使用率很高，计划把内存给占满了，这个现象正常吗？
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
AskTUG 上有比较多关于 TiKV 内存占用高的帖子，可以先参考一下，按照别的帖子看下是否符合情况
1 个赞
查了一下，可能是tikv的 storage.block-cache.capacity 参数配置的有点大。
调整这个参数后是不是需要重启tikv组件？重启的时候需要注意什么吗？
我还需要修改其他tikv参数（不支持再现调整），我想把tikv节点依次重启，那么会影响应用的连接吗？会出现闪断吗？
会对应用有一些影响，建议在业务低峰期操作。
如果要对业务无影响，可以依次在每个 store 上加 evcit-leader-scheduler 迁移对应节点的 leader ，等该节点上 leader 都迁移到别的节点之后，reload 对应节点，然后照样依次修改别的节点配置，这样基本对应用无感知，但是操作比较繁琐。
1 个赞
这个影响是什么影响？是应用等待还是应用会有连接报错？如果只是等待一会，那还是可以接受的？
会访问报错，因为短时间内一个 store 上的 leader 会无法提供服务，重新完全选举出所有的 leader 会需要一定的时间。
具体可以在测试环境尝试下，比较容易理解
那要是这样的话，是不是缩容tikv的场景也会出现应用访问报错？
缩容 TiKV 的时候会先将要下线的节点上的 region 都迁移到别的 store 上。然后停止 TiKV 进程。这样应用是无感知的。
添加 evict-leader-scheduler 的效果也是一样的，等于将 leader 迁移到了别的正常的 TiKV 进程上继续服务，对应用无感知。
tiup cluster reload 的时候是直接滚动重启 tikv 节点，没有迁移 leader 或者 region 的过程。
哦，明白了。
那如果我事先把leader调度到别的store上，那这个leader调度的过程不会对应用的访问有影响吧？
不会，可以在测试环境演练一下
我查看reload tikv过程的显示内容，是有leader的调度的呀？
Restarting component tikv
Evicting 1 leaders from store xxx.xxx.xxx.xxx:20160…
Still waitting for 1 store leaders to transfer…
Still waitting for 1 store leaders to transfer…
Still waitting for 1 store leaders to transfer…
Still waitting for 1 store leaders to transfer…
Still waitting for 1 store leaders to transfer…
Restarting instance xxx.xxx.xxx.xxx
Restart xxx.xxx.xxx.xxx success
Delete leader evicting scheduler of store 12 success
Removed store leader evicting scheduler from xxx.xxx.xxx.xxx:20160.
Evicting 3 leaders from store xxx.xxx.xxx.xxx:20161…
Still waitting for 3 store leaders to transfer…
Still waitting for 3 store leaders to transfer…
Still waitting for 3 store leaders to transfer…
Restarting instance 10.19.241.9
Restart xxx.xxx.xxx.xxx success
那就是我记错了
那这样的话，是不是对应用就没有影响了呢？
可以在测试环境验证一下，不同业务对数据库运行状态敏感度应该是不一样的。以具体业务测试情况为准。
我设置了这个参数，重启后占用内存小了，但是运行一段时间后占用内存又会增大。你的又出现吗？
我们的更高，数据库占内存，没啥错。