多租户资源规划需先划边界、再留余量、最后动态调：按租户角色设QoS基线，用cgroup v2实现CPU/内存硬隔离，结合调度器分层管控，并预留缓冲与监控联动。
多租户环境下，CPU 和内存不能靠“均分”或“凭经验估”，必须结合隔离机制、业务特征和运行时约束来规划。核心思路是：**先划边界，再留余量，最后可动态调**。
按租户角色定配额基线
不同租户对资源的敏感度和波动性差异很大：
-
核心业务租户（如订单、支付）：优先保障 CPU 时间片和内存下限，建议使用
GuaranteedQoS 级别（K8s）或 cgroup v2 的cpu.min+memory.min，避免被抢占 -
分析类租户（如报表、离线任务）：允许弹性伸缩，适合
Burstable级别，设合理上限（cpu.max/memory.max），防其突发拖垮他人 -
低频租户（如测试环境、小商家）：可设极低基线（如 0.1 核 / 512MB），启用
cpu.weight控制相对权重，不占硬配额但保基本可用
用 cgroup v2 实现硬隔离（Linux 主机/容器底层）
这是最直接有效的手段，尤其适用于非容器化或自研调度场景：
- CPU 隔离：在
/sys/fs/cgroup/下为每个租户建子目录，写入cpu.max（如50000 100000表示最多用 50% CPU 时间）、cpu.weight（控制同级竞争时的份额） - 内存隔离：设置
memory.max（硬上限，超限触发 OOM Kill）、memory.min（保障最小可用内存）、memory.low（软保障，内核优先不回收这部分） - 关键提醒：启用 cgroup v2 需确认内核 ≥ 4.15，且禁用 v1；生产环境务必关闭
swap，否则内存隔离失效
结合调度器做分层管控
单靠 cgroup 不足以应对复杂负载，需叠加上层策略：
- Hadoop/YARN 场景：用
CapacityScheduler划队列，为每个租户分配capacity（最低保障）和maximum-capacity（弹性上限），再通过 NodeManager 的 cgroup 插件落地 - OceanBase 社区版：在
CREATE TENANT时指定UNIT_NUM、MAX_CPU、MEMORY_SIZE，资源单元（Resource Unit）自动绑定到 OBServer 节点的 cgroup 组 - LangGraph 类 Agent 服务：对高风险节点（如 PDF 解析、代码执行）单独启进程池，并用
prlimit或subprocess.Popen(..., preexec_fn=set_cgroup)限制子进程资源
预留缓冲与监控联动
硬配额不是一设了之，必须配套可观测性和弹性机制：
- 主机层预留 15–20% CPU 和内存给系统进程和突发缓冲，避免因资源耗尽导致 ssh 登录失败或日志写入卡住
- 对每个租户暴露
cgroup.stat、memory.current、cpu.stat指标，接入 Prometheus；当throttled_time > 0或oom_kill计数上升，自动触发告警并临时上调配额 - 避免“一刀切”限频：例如大模型推理租户，应区分
prefill（CPU 密集）和decode（内存/显存密集）阶段，分阶段调整 cgroup 参数
