Resource Unit 是已消耗的资源RU情况，您评估的 rru和wru有是怎么参考的？
比如读写请求 5:1，要怎么分配ru呢
补充说明：对于余量或者可用总量，还是没法确定。
rru和wru,那个高就应该根据那个来设置ru的上限，好比写ru1000,读ru5000.这种5:1的情况。
假如你设置的ru比5000低，其实就是限制了的读的速度。会导致qps下降的。
你的补充说明的观点是对的，如果一个系统承载的业务总和已经大于了他的整体硬件资源要求，这个时候要求稳定优先，读写可以慢点做，现在这套资源管控是胜任的。
如果你的系统还没建立，想要通过一个空集群的预估ru值来评估能否支撑一个现有业务是比较困难的。
毕竟你老的系统不太可能会有类似的ru值。
这就必然存在一个不设置ru上限，来观察读写ru最高值,再设置ru上限的过程。混合业务还要注意区分读写。
了解了，还有一个问题。RU计算集群中单台tidb-server还是多台？这样计算是如何考虑的呢？
当前场景：
研发打开metabase只读面板，会开启较多统计查询，导致ru消耗冲高。但整个集群的tikv、tidb负载无明显冲高（metabase连接的单点tidb-server负载偏高）
staticCalibrate应该就是基于硬件估算的具体计算方式。
我看了下，应该是每个tidb和tikv的cpu利用率都算了一遍的结果。
但里面有些静态数据设置的依据我不了解。
这个看上去像是没有使用haproxy这类的负载均衡，直接连接了tidb。实际是这样嘛？
如果是的话，可能确实只会有一台tidb的cpu会冲高。
还有就是如果metabase面板里面的聚合类sql比较多，请务必尝试一下tiflash+mpp。可能会有惊喜。
我这边用的也是tidb+metabase.大表的聚合查询用上了tiflash+mpp,效果非常好。
集群的负载上限 RU 数量并没有一个固定值，取决于多个因素，例如集群规模、硬件配置、数据访问模式等等。通常可以通过压测等方法来测试集群的性能和容量，然后根据测试结果来确定合适的负载上限 RU 数量。
是的，多谢大佬给提示，我这边也整理下场景，梳理优化。
这玩意感觉要跟部署环境，机器配置什么的都有关
还有一个问题，资源管控有没有监控告警，做到前置发现资源不足问题。避免影响业务后，再被找。
刚刚查了，好像没有具体某一个资源组资源超限告警，有总资源的监控指标。初步评估告警缺少适配性。
这些还真没测试过
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。