【TiDB 使用环境】生产环境
【TiDB 版本】8.5.1
【操作系统】centos7.9
【部署方式】私有云
【集群数据量】
【集群节点数】6台+1台监控节点+2个haproxy代理节点
【遇到的问题：问题现象及影响】
咨询下关于资源管控的问题，麻烦大佬们帮忙一起看看，谢谢>.<
背景：
现在从tidb的dashboard上看到，集群的oltp_read_write估算RU是81,638RUs/sec,oltp_read_only场景只有28,412；而oltp_write_only是有219,552；而这个tidb集群上已经有了三个生产的数据库；目前是没有做资源管控的，每个库默认绑定的是default资源组；
疑问：
1、我现在如果做资源限制的话，这个RU该如何合理的分配
2、我从dashboard的SQL语句分析上看db1的有几条SQL的平均RU，有的达到50000甚至有的达到90000；我如果给db1的RU限制到50000，那读是不是就相当于没做限制，写会有限制；但是如果设置RU为10000，这种情况，是对读做了限制，但是写排队的时间是不是就更久了？
3、集群上所有数据库分配的总的RU，能超过集群预估的RU吗？当某一条sql超过超过我设置的RU大小后，这条SQL的行为是什么？是被限流等待RU回填后继续执行，还是直接被中断？
4、如果每个资源组都加上BURSTABLE，允许超限额使用，是不是相当于都没限制资源了？
限制到50000，业务高峰期会造成SQL排队或执行速度下降
1 个赞
那我这个集群，岂不是只能给这个db用了 
总共才80000的RU，这个db就得50000
根据你说的第二点推测的 
dashboard 估算的 RU 应该不一定准确，仅供参考的吧。按照实际业务运行时所消耗的资源按照比例分配 RU 就好了
1，ru是个很模糊/抽象的东西，只能凭感觉设置，如果设置了没限制住，再想办法调整。确实很反直觉，但是pingcap CTO推崇这个做法。在去年tidb走进b站——tidb上海站活动时，CTO也是这么说的。
2，50000还可以接受。90000的是真的需要优化一下sql了。
这个ru用的令牌桶算法。这是个经典的限流算法。所以整体超出ru上限的时候是按照限流来处理的。90000的sql你设置50000，那就是多执行1倍的时间，你设置10000，就是多执行9倍的时间。
3，
集群上所有数据库分配的总的RU，能超过集群预估的RU吗？
可以，但不保证稳定。只在你明确知道这几个db的负载是错开的情况下，考虑这种分配方法。
可以参考这个
当某一条sql超过超过我设置的RU大小后，这条SQL的行为是什么？
2里面解释过了。
是被限流等待RU回填后继续执行，还是直接被中断？
默认是限流，也可以被中断。参考
4，BURSTABLE只是允许临时超过一会，这个时间不会很长。直接不允许BURSTABLE确实会让你的系统更稳定。我上面那个文章里面提过这一点。
我们现在也是上了生产，然后当前是每个库一个用户，而这个库的读写也都是同一个账号，集群估算oltp_read_only场景只有28,412；而oltp_write_only是有219,552；
我现在就跟你这里提到的场景类似，我们并没有做读写分离，且读和写，都是一个账号，哪怕我现在从tidb的dashboard知道，这个库有些SQL达到了50000，我也不敢设置RU为50000；因为我的oltp_read_only只有2万+ ，拿上面说的有的sql达到90000，就算这是个写的sql。如果我设置RU为50000，那这个库的读的RU相当于压根没限制住，只是限制了写。但如果我按最大读RU的2万设置，那超过2万RU的写一定会被限流，导致写进一步变慢。所以很难平衡这个RU该怎么设置；再者，我这个tidb集群，还不止一个库，我还得给别的库留点资源
1 个赞
我们也在生产上面用了RU资源管控，主业务不做限制，（oltp_read_write）54,425，（oltp_read_only）18,941 （辅助业务）一个5000可突发，（辅助业务）一个5000不可突发。根据业务重要程度区分。资源有限，防止辅助业务影响到主业务，同时也是根据研发这边规范程度，规范的限制就小点。不太规范的限制大些。通过sql语句上能开出来是哪个研发组。目前是这样
1 个赞