1 个赞
3.x用的软隔离，缺点是不同租户负载不一样，如果一个租户负载过高，工作线程多，会占用过多的CPU资源，影响其他租户。
4.x用cgroup做资源硬隔离，避免3.x出现的这类情况。 目前生产角度都推荐用硬隔离（默认方式）
在 OceanBase V4 版本中，推荐使用基于 Linux cgroup 机制的“硬隔离”方式。
以下是两种 CPU 隔离方式的具体对比和推荐理由：
1. 硬隔离：基于 Linux cgroup（推荐方式）
-
实现机制：OceanBase 为后台线程和不同租户的工作线程分配不同的 cgroup 目录，根据租户配置的
MIN_CPU和MAX_CPU设置 cgroup 目录内的 CPU 使用限额。 -
核心优势：
- 互不干扰：租户的 CPU 使用不会超过其资源配置的上限，即使一个租户业务异常繁忙，也不会影响到集群内的其他租户。
-
精细控制：系统负载高时按
MIN_CPU权重分配（对应cpu.shares），负载低时按MAX_CPU限制上限（对应cpu.cfs_quota_us）。
- 推荐地位：这是 V4 版本的默认隔离方式。通过 OCP 部署时会自动配置，命令行安装时也建议手动配置开启。
2. 软隔离：限制线程数量
-
实现机制：通过租户配置项（如
cpu_quota_concurrency）控制每个 CPU 配额对应的活跃工作线程数量（默认为 CPU 配额的 4 倍）。 -
主要缺陷：
- 隔离性弱：由于工作线程数通常远大于物理 CPU 核数，租户实际上可以使用超过其限额的资源。
- 资源争抢：一旦某个租户 CPU 使用过高，会直接干扰并恶化其他租户的性能。
总结
为了保障多租户环境下的业务稳定性，避免“坏邻居”效应，应优先使用 cgroup 硬隔离。只有在操作系统不支持 cgroup 等极少数特殊情况下，才会退而求其次使用线程数控制的软隔离。