【 使用环境 】测试环境
【 OB or 其他组件 】OBSERVER
【 使用版本 】4.1.0以上
【问题描述】
https://www.oceanbase.com/docs/common-oceanbase-database-1000000000034071
https://www.oceanbase.com/docs/common-oceanbase-database-1000000000035102
您好，这个参数调优参考和参数解释里面好像有点不一样，是cpu分配多的话调低cpu_quota_concurrency，还是cpu分配多的话调高cpu_quota_concurrency？
【复现路径】问题出现前后相关操作
【问题现象及影响】
【附件】
这两个说法都不太准确，后面我们修正一下，主要原因是这个参数在4.x版本改为了租户级配置项，而调优手册是4.x之后出，所以会有一些出入。
当物理机 CPU 足够多时，可以适当调大
cpu_quota_concurrency的值；如果物理机 CPU 较少，则调大cpu_quota_concurrency的值会存在风险。
这个说法有问题的地方在于，当时的背景是该配置项为集群级配置项，且假定分配给租户的cpu并不多，调大可能导致某些租户cpu的cpu使用被挤占。
对于 CPU 配置较大的租户，该参数值尽量调低，反之调大。
这个说法同样有问题。
其实这个参数大部分场景不需要改，改大改小都不意味着性能一定会变好或变差，甚至可能会有稳定性风险，如改小可能会有队列积压甚至死锁，改大可能会导致内存爆或cpu超卖打爆，需要有比较资深的调优经验配合一些诊断数据来修改，如sql audit中的queue time（但也不意味着一定会变好）。
经验来看，tp类尤其是类似sysbench中point select的模型，适合调小，比如调到2，一些耗时较长较大的查询，如ap类查询、分布式事务，可以适当调大到6甚至8。
默认值4是一个经验值，意味着ob的工作线程在大部分业务场景里只有1/4的时间处于cpu time，因此在没有cgroup时需要4倍的并发数去保证租户实际cpu消耗尽量接近租户cpu配额。
了解，感谢回复
借题请教下：非 Cgroup 隔离场景，如果发现租户 queue_time 较大，但OBServer CPU 使用率不是很高的时候，是不是可以调大点。
非生产可以试试，但经验来看效果一般不大，和场景强相关，如非常典型的多分区分布式事务，全局索引，需要从schema/索引/sql入手。
