楼主问集群能否重启，首先你要确认是测试环境还是生产环境，如果重启会有什么风险。
考虑到你这边对TiDB还不是特别了解，可以先确认有什么业务在访问，集群异常会影响到谁，先通知到位。
然后再来调整这个内存使用高的问题，tikv使用内存过高是很少见的，大部分场景是因为同一台机器部署了多个节点导致资源竞争厉害，或者是tikv的参数 storage.block-cache.capacity 配置不合理，先往两个方向排查和确认，如果是就可以针对性解决。
加油了，试试万能的重启
用tiup来操作吧
这边不建议重启，你直接先看下storage.block-cache.capacity这个值设置多少
SHOW config WHERE NAME LIKE ‘%storage.block-cache.capacity%’;
然后修改为原来的一半左右，参数立即生效，内存很快释放。
SET config tikv storage.block-cache.capacity=10G;
tikv内存使用95%,有性能问题吗？有影响业务吗？如果没有，通过日志，dashboard来分析原因；如果有，跟业务方沟通确认是否可以重启
每个服务器都登录下试试tiup命令能不能运行，root和tidb用户都试试
直接重启风险太大
只是单纯的高，还是有性能问题了
1、每个机器which tiup看中控在那台机器上
2、是否混合部署？
3、看下storage.block-cache.capacity这个值
修改 SET config tikv storage.block-cache.capacity=10G; 不是混合部署的情况下 给机器内存的45% 左右
3、看监控 granfa 的 tikv detail → rocksDB KV → Block cache size 是否在storage.block-cache.capacity 设置的范围内
4、可直接重启对应 node 降低内存
1 个赞
重启解决一切
有没有混合部署呢
试试重新启动 不知道服务器具体配置也不好下结论
你中控机都找不到还要重启这个tikv实例？你确定这样不会背锅嘛？
如果是离职交接的原因该叫就叫啊。现在叫不会是你的错，但是你不叫，重启出了问题，肯定就是你的问题了。
这也太离谱了交接的 
，谨慎操作
想办法甩锅吧
先看操作系统的日志
如果tiup重启集群，不行再重启主机试试。
找集群文件采集信息吧
这种不好搞啊谨慎操作
众所周知，百分之95的问题可以靠重启解决