架构：juicefs + tikv
tikv 版本 v8.1.0
3 pd (8c16g)
3 tikv (32c64g)
背景：最近在juicefs summary 回收站，业务反馈 juicefs 文件系统 ls 卡顿，亲自测试确实卡卡顿，juicefs summary 停掉 马上恢复，所以首先怀疑是tikv的问题
补充统计多次出现
gRPC监控
指标低于 80% * server.grpc-concurrency 80% * 5 =400%
schedule监控
Raftstore 线程池监控
UnifyReadPool监控
StoreWriter 监控
RocksDB 线程池
ls命令卡顿，有没有可能是文件数量太多
不是，文件夹下，就10几个文件
在juicefs summary 回收站有很多数据吗？
很多小文件 亿级别的
这也太多了，确实会影响性能啊。。。。不能清理吗？
另外，常规的清理速度可能也特别慢，如果业务可行，mv 文件夹，然后重建文件夹，这样的方式比较好。
我 juicefs summary 回收站 就是想要并行清理数据，因为里面有1P的数据，想要清理掉，太大并发还不行，会影响业务
要控制速度，不然把IO占完了，整个系统都会卡住
Summary 回收站背后纯读取吗，大致逻辑是什么？
看目前的监控，主要是 unified read pool 的负载比较高
可以再看一下 grafana 的 TiKV-Details → Unified Read Pool
这个场景看起来 juicefs 没对 tidb 做优化支持…
unified read pool 的负载比较高，但是 tikv 实例的节点是 32C，
即使 1000%，也才用 10C…
有没有机会在扩一些硬件资源，来缓解资源释放上的压力？
这个我理解三台tikv 实例 本身cpu占用不高，在扩展有意义吗
感觉你的tikv当前是个非常偏重读取的状态。
应该适当增加UnifyReadPool线程数，和grpc的线程数。
https://docs.pingcap.com/zh/tidb/stable/tikv-configuration-file/#max-thread-count
https://docs.pingcap.com/zh/tidb/stable/tikv-configuration-file/#grpc-concurrency
这两个图形的波动也是高度一致的。是有明显的瓶颈，特别是UnifyReadPool。
参数可以调节的，但是硬件资源不够，就没调整的空间了，有机会的话，可以试试
