【OceanBase】CPU资源隔离

相比于内存，CPU 是更弹性的资源，所以 OBServer 目前允许一个 Unit 使用的物理 CPU 超过分配给它的配额。
在 OceanBase 数据库 V3.1.x 版本之前，主要通过控制线程数来控制 CPU 的占用；在OceanBase 数据库 V3.1.x 及之后的版本，允许配置 Cgroup 来控制 CPU 的占用。

OBServer 会启动很多不同功能的线程，细化的分类请参考ObServer线程的相关章节，本节按照最粗略的标准可以分为以下两类：

• 一类是处理 SQL 和事务提交的线程，统称为 Worker 线程。
• 其余的是处理网络 IO、磁盘 IO、Compaction 以及定时任务的线程。

Worker 线程是分租户的，非 Worker 线程是所有租户共享的。本节的租户 CPU 隔离都是针对 Worker线程的。

基于线程数的 CPU 隔离

Unit 的 CPU 隔离是通过一个 Unit 的活跃 Worker 线程数实现的。
由于 SQL 执行过程中可能会有 IO 等待、锁等待等，所以一个线程无法用满一个物理 CPU，故在缺省配置下，OBServer 会给每个 CPU 启动 4 个线程，4 这个倍数可以通过配置 cpu_quota_concurrency 来控制。这就意味着如果一个 Unit 的 MAX_CPU 是10，那么它能同时运行的活跃线程是 40，最大物理 CPU 的占用是 400%, 也就是 10 个 CPU 被超卖成了 40 个 CPU。

基于 Cgroup 的 CPU 隔离

开启 Cgroup 后最大的变化是不同租户的 Worker 线程放到不同的 Cgroup 目录内，租户间的 CPU 隔离效果会更好。最后的隔离效果如下：

• 如果一个 OBServer 上只有一个租户负载很高，其余租户比较空闲，那么这个负载高的租户的 CPU 可以超过 MAX_CPU 的限制，超卖倍数仍然受 cpu_quota_concurrency 控制，这个行为主要是为了兼容。
• 延续上面的场景，如果有多个空闲的租户的负载上升了，导致物理 CPU 不够了，Cgroup 会按照权重分配时间片。

大查询处理

我们认为相比于大查询，让短查询尽快返回对用户更有意义，即大查询的查询优先级更低，当大查询和短查询同时争抢 CPU 时，系统会限制大查询的 CPU 使用。
当一个线程执行的 SQL 查询耗时太长，这条查询就会被判定为大查询, 一旦判定为大查询，执行大查询的 Worker 会等在一个 Pthread Condition 上，这样就为其它的 Worker 线程让出了 CPU。
具体实现上，OBServer 在代码中插入了很多检查点，Worker 线程在运行过程中会通过检查点定期检查自己的状态，如果判断应该挂起，那么线程就会等待在一个 Pthread Condition 上，等到合适的时机再被唤醒。
如果同时有大查询和小查询，大查询最多占用 30% 的 Worker 线程，30% 这个百分比值可以通过配置项 large_query_worker_percentage 来设置。

有两点需要说明：

• 当没有小查询的时候，大查询可以用到全部的 Worker 线程。只有当同时有大查询和小查询时，30% 的比例才生效。
• 一个 Worker 因为执行大查询被挂起时，作为补偿，系统可能会新创建一个 Worker 线程，但是总的 Worker 线程不能超过 MAX_CPU 的 10 倍，10 这个倍数可以通过配置项 workers_per_cpu_quota 来设置。

提前识别大查询

由于 OBServer 挂起一个大查询线程，就会启动一个新的 Worker 线程, 但是如果有大量大查询涌入，OBServer 新创建的线程还是被用来处理大查询，很快达到 Worker 数上限，在这批大查询消耗完之前就没有机会再处理短查询了。
为了优化这个场景，OBServer 会在 SQL 开始执行之前预判它是不是大查询，预判的本质就是估计 SQL 的执行时间。预判主要依据以下假设场景：如果两条 SQL 的执行 Plan 是一样的，可以猜测它们的执行时间也是相似的，这样就可以用 Plan 最近的执行时间来判断 SQL 会不会是大查询。
如果某条 SQL 被预判为大查询，那么该查询就会被放入一个特殊的大查询队列，其 Worker 线程会被释放，系统就会接着执行后面的请求了。