用于设置系统 CPU 总数的cpu_count 参数不生效

OceanBase
,
#1

【 使用环境 】测试环境
【 OB 】
【 使用版本 】ce v4.0.0
【问题描述】alter system set cpu_count = 8; 之后执行 benchmarksql 发现observer cpu 使用率仍超过800%
【复现路径】alter system set cpu_count = 8;
因为计划在一台高配物理机通过控制CPU/内存使用量，模拟低配机型测试ob4.0 性能；
cpu_count 在设置为小于物理机逻辑CPU 数量时不生效
observer 实际CPU 使用率上限是否可以严格控制？
另外所用租户的 max_cpu = 4、cpu_quota_concurrency 与 workers_per_cpu_quota 为默认值；
如何严格设置单个租户的CPU、内存使用量？

#2

关于强制限制租户资源占用部分可以看下https://www.oceanbase.com/docs/community-observer-cn-10000000000901426 下面的资源隔离部分

1 个赞
#3

看到了，但还是不太清楚对于CPU 如何严格限制使用率

  1. observer 的 cpu_count 当设置为小于服务器总的逻辑cpu 数量时，例如cpu_count 设为 4，是否通过top 观察到的 observer 的 cpu 使用率最高只能达到 400%?
  2. 在服务器cpu 数量较大，但设置的 cpu_count 较小的情况下，租户的 max_cpu * cpu_quota_concurrency 的值是否可以超过 cpu_count？是否会导致 observer 的 cpu使用率超过 cpu_count*100%?

对于上面疑问1，我修改 cpu_count 后观察到仍会超过预期值

另外文档中“在 OceanBase 数据库 V3.1.x 及之后的版本，允许配置 Cgroup 来控制 CPU 的占用。” 可以理解为即使是4.0 的observer 默认也不是CGroup 的方式，需要额外手动配置成CGroup的控制方式吗？

#4

对于cpu_count变量生效部分可以看下这里https://www.oceanbase.com/docs/community-observer-cn-10000000000900550

#5
  1. 在操作系统里，通常只有操作系统才可以决定每个进程能用多少CPU。如果想干预某个进程的CPU利用率，可以使用cgroup的CPU隔离技术对该进程的CPU利用率进行控制。 云厂商的云数据库CPU隔离基本上用的是cgroup隔离技术。
  2. OB是单进程软件，设计上启动后会将主机的绝大部分资源（CPU、内存和磁盘）据为己有，然后在OB内部做资源的二次分配（即多租户技术）。4.0之前OB内部只有CPU、内存的隔离，4.0后新增 IOPS的隔离。这些说的是OB内部的资源分配。内部租户资源的调整会在主机层面OB进程的CPU利用率上有一定体现，但不是绝对对应。
  3. cpu_count 这个值默认取的是主机逻辑cpu个数，然后OB内部再瓜分这个 cpu个数（会保留2个，名为给OS留点）。如果你想在高配机器上模拟低配机器跑OB（即低CPU），你可以将 cpu_count设置为比实际cpu少。但是，它并不等于你在OS里看到的进程CPU利用率，因为在主机层面,CPU大管家是OS，而不是某个进程。不过进程如果能够自己主动绑定某几个CPU，倒是可以自觉的将自己能利用的最大CPU利用率控制在一个比例以内。OB 没有这个参数。在OS里通过CPU绑核命令倒也是可以，但还是比较麻烦。要达到你的目的，最好的办法就是 用cgroup的CPU 去限制。按比例限制或者绑核限制都可以。
  4. 在一个低配的机器（如容器），实际CPU个数不够16的时候，是可以直接将 OB的cpu_count参数设置为16.或者设置为其他任何比16大的值（看看OB Docker容器里设置）。18,20,32,64,128. 不管你设置为多少，这个数是内部CPU资源分配时可以瓜分的“和”，是影响租户内部CPU利用率的分母。OB能最大拿到多少CPU是看OB进程在OS层面能获得多少CPU利用率，跟OB内部设置的 cpu_count 应该没有关系。

个人观点，随着OB版本发展，可能理解有不对的地方，欢迎指出。

1 个赞
#6

分析的很详细，赞；
我尝试理解一下：
其实从可行性上是可以通过CGroup 来实现observer 进程自行控制cpu利用率的，但目前cpu_count 并不是用来实现这个总体cpu利用率控制的目的，而是被作为内部资源分配的分母；
因此现在如果想要实现observer 进程的利用率严格控制，或者是模拟低配机器，只能自行手动用CGroup 来实现控制。
是这样吧？

#7

这个文档我也看了，感觉并不能让人更好的理解cpu_count参数的意义 ,这也是我想对系统参数文档提的一个建议，这些参数好像文档都给了解释，但好像很难去真正理解参数能做到什么，不能做到什么，真正的含义和使用场景是什么

#8

基于早期版本的功能原理和文档，我理解当前是这样。不排除OB 后续对CPU资源的调度策略继续改进。

#9

这个值更多地是用于对observer本身资源分配去做出限制。在限制CPU实际占用实现上，现在cgroup是支持的。可以按文档挂载对应的cgroup去实现绑核（想要快速试用可以使用ocp部署，大都情况下自动挂载）对于对应租户所占用的cpu量可以使用如下命令获取，top -d 2 -H -b -n1 | grep ${tenantid} | awk ‘{total+=$9}END{printf “total=%s\n”,total}’

2 个赞
#10

目前官网有挂在cgroup 实现绑核的详细文档吗？

#11

这边看了下，好像没有放手动绑核的文档，这边先内部沟通下。可以用ocp（4.0版本）来部署observer来体验下cgroup，ocp在官网下载页可以下载（OceanBase 社区 ）

1 个赞
#12

后续OBD也会支持在部署时加入支持

#13

好的，我试下。
是否ocp4.0 可以支持部署和管理ob4.0 单机节点？

通过ocp4.0 修改接管的ob 单机节点cpu_count 就可以实现手动绑核+CGroup 限制observer 的CPU 使用率在 cpu_count 以下是吗？

#14

目前ocp部署和obd部署在此方面主要区别是在OceanBase部署的目录下是否挂载cgroup分区，同时在打开 enable_cgroup（ https://www.oceanbase.com/docs/community-observer-cn-0000000000964007 ）可以实现绑核执行。即实现对max_cpu的确定性限制。
补充：原无cgroup限制的情况下在调大cpu_quota_concurrency的情况下可以超过对租户的max_cpu限制

1 个赞
#15

好的， enable_cgroup 打开后能实现租户的 max_cpu 确定性限制，这个我去试试；
是否同样能达到 observer 进程的 cpu_count 确定性限制？因为除了租户的线程之外，observer 其他线程数量目前好像可以超过 cpu_count 的限制，如果不可以，是否有其他参数可以做到？

#16

目前没有针对 observer 做 cgroup 的限制。只限制了 observer 下面的各个租户。对于是否需要限制observer总的进程占用目前认为不该在observer本身去进行软限制，而是通过所在容器去进行限制，如果有不同的意见也可以提对应的issue，内部会进行对应决策

#17

上面解释了大部分原理，对于你这个case，如果不想开cgroup，两个策略规避

1、调低租户min_cpu，调max_cpu对tp没啥用，当然这个也不是正路；

2、调小cpu_quota_concurrency，默认是4，tp可以放到2或更小，推荐试试这个策略；

改cpu_count没啥用。

#18

MAX_CPU 和 MIN_CPU 表示使用该资源配置的资源单元能够提供的 CPU 的上限和下限。CPU 规格最小为 1C。必须指定 MAX_CPU 规格，MIN_CPU 为可选，如果不指定，默认等于 MAX_CPU。

租户min_cpu 控制啥呢？能起到什么效果？您意思是min_cpu和 max_cpu 同时调低是么？

这个case 我的需求主要还是高配服务器上模拟低配服务器部署并运行observer 单节点，cpu_quota_concurrency 也是租户的参数，做不到严格控制 observer 进程的CPU 使用吧？

我现在的 max_cpu 调到2，cpu_quota_concurrency 默认应该是4，这跟我设置 max_cpu =4，cpu_quota_concurrency = 2 有啥区别？

#19

max_cpu是给大请求用的，在tp场景基本没用。

租户的worker线程数量直接影响cpu使用量，在tp场景可以约等于min_cpu * cpu_quota_concurrency。

如果你想严格控制，只能上cgroup或者taskset之类的工具从外部限制。