【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】7.1.0
咨询：如何查看TiDB资源管控总量上限？
在dashboard中查看到消耗总量226K RU，
疑问：
1、集群的负载上限RU数量是多少？
2、tidb层面使用haproxy 高可用，RU总量是计算的所有TiDB的cpu/io/网络资源吗，如果是，机器配置存在差异如何配置资源组的RU？
背景：
1、需要规划生产的资源隔离，调研如何判断生产的资源总量。
2、使用官方【负载方式预估 】资源总量只有164K多个数据相差较多，以哪个为准。
这个要看生产实际情况吧，一是机器配置，二是生产负载
近期也想研究这个资源管控，关注了此贴
不应该是先预估并发数，然后做个压测，评估资源总量吗，如果不够在加
应该不是，做方案才能落地，做方案需要统计总量。如果反着来，耶稣也保不住啊。
是的，但是总量没有的话，没法给每个业务划分资源。
应该是先根据生产大概预估一个资源，然后按生产的预计并发对当前资源做压测，满足就ok，不满足就加资源
做方案要有依据，不敢直接拍脑门。
压力测试怎么能叫拍脑门呢， 
集群资源的评估，一开始确实只能通过系统自动根据硬件配置来计算得到总RU量，然后根据这个估计得到的量，创建资源组、分配租户。
运行一段时间后，会根据这段时间的实际负载获得准确的总RU和消耗量，这个时候还需要管理员介入，再次调整之前不同租户的资源组所持有的分配额。
可以在测试环境中先做一些测试和观察，然后再类比预估上生产环境的机器情况、推断所需要的总RU量。
这块内容，好的方面是，官方也很重视、在持续推进优化，包括你提到的问题，以及管控的范围、方式等。
一步一步来吧。
了解，上线前规划方案“无法确定总量”成为项目卡点，已经阻塞功能特性上线。
实际上目前有统计过最大的数据量吗？
数据量吗？还是资源的容量？
希望官方同学给准确答案。
感觉ob 的资源管控比tidb 要强一点
现在第一步【评估总量】都开展不了，更不能提落地。
1，根据硬件资源估算的基本靠谱，根据负载计算的ru数值，会因为时间范围内的负载情况，有较大的波动。我自己的实践中，根据后者配置ru的话，tikv可能会挂。
2，你应该能发现，即便选择根据硬件估算，进入这个页面之后评估方式选oltp_read_only/oltp_write_only，评估出来的ru也有很大程度的波动。这两个评估方式的值大致可以视为读ru和写ru的最大值。
根据我的观察前者依赖你单台tidb服务器的配置，后者依赖你tikv的个数。
也就是说，大部分情况下，tidb集群的读ru和写ru的最大值并不一致。在 grafana里面可以更新一步的看到rru和wru的监控数据。
多谢大佬。大概理解了。
我们这边单集群有6个tidb-server，基于硬件估算的RU值只算单台tidb值吗。
目前观察到基于负载评估结果高时，tikv CPU负载也比较高。
我这边情况基于硬件估算结果远大于“基于负载评估”，但基于负载评估的消耗RU较高（接近硬件估算的2/3）时，tikv集群负载就比较高，达到90%左右.
同一个集群读写ru上限一般来说并不一致。从实践上看，根据硬件估算->oltp_read_only，大致是读ru的上限。硬件估算->oltp_write_only,大致可以看做写ru的上限。
好比我的集群，硬件估算->oltp_read_only这个算出来的ru只有4000,但是硬件估算->oltp_write_only的ru可以到3w.如果我执行批量导入，可以很容易的观察到ru到3w.
如果没有导入，只执行select,ru到了4000，不控制也很难继续往上。
所以用户执行的负载是重读还是重写，是比较重要的一个问题。特别是这两个差距大的情况下，如果我给一个重写的用户只给4000，那导入速度一定很慢。对混合负载，是一定要去 grafana里面看看的。位置在 grafana ->TiDB-Resource-Control->Resource Unit。
这个里面可以看到rru和wru.
我测试下来也是这样的。如果我根据基于负载评估的结果来做实际ru设置，也许真的可以跑这么高，代价可能就是tidb或者tikv不稳定了，后续我就没有采用这个评估方式。
