MongoDB 6.0 不支持资源组（resource_group）机制，其配置文件 mongod.conf 中无 CPU_RATE_LIMIT、MEMORY_LIMIT 等字段；资源隔离需依赖操作系统 cgroups、Kubernetes 容器限制或分片标签路由等外部手段实现。
MongoDB 6.0 本身不支持 Resource Group（资源组）机制——这是 AnalyticDB PostgreSQL 6.0 的功能，不是 MongoDB 的能力。直接在 MongoDB 中配置 CPU_RATE_LIMIT、CONCURRENCY 或 MEMORY_LIMIT 等参数会报错或被忽略。
为什么找不到 mongod.conf 里的 resource_group 配置项
MongoDB 的配置文件（mongod.conf）中压根没有 resource_group、CPU_RATE_LIMIT 这类字段。它的资源控制粒度不在数据库进程内，而依赖外部调度层：
- 操作系统级：用
cgroups v2+systemd限制单个mongod进程的 CPU quota 和 memory max - Kubernetes 级：通过 Pod 的
resources.requests.cpu和resources.limits.cpu控制容器资源边界 - 分片集群内：靠
mongos路由 + 标签（tag）+ 区域（zone）把特定租户的读写定向到指定分片，实现逻辑隔离，但不提供 CPU 百分比配额
多租户场景下真正可用的 CPU 隔离手段
如果你的目标是让租户 A 的查询不抢租户 B 的 CPU 时间，必须绕过 MongoDB 自身限制，采用以下实操路径：
- 每个租户独占一个分片（或一组带相同 tag 的分片），用
sh.addShardTag()和sh.addTagRange()绑定分片键范围，避免跨分片扫描 - 为每个分片节点的
mongod进程单独建 systemd service，并启用CPUQuota=40%（例如限制最多用 40% 的单核等效时间） - 在 Kubernetes 中部署时，给每个租户对应的 StatefulSet 设置硬性 limit：
limits.cpu: "2"，并确保节点有足够 CPU 可压缩（避免 CPU Throttling） - 禁用
mongos的连接池共享（设置maxPoolSize按租户拆分），防止高并发租户拖垮路由层
常见错误：误把 Ops Manager 的“资源监控”当“资源控制”
Ops Manager 或 Cloud Manager 提供的 CPU 使用率图表、告警阈值（如 cpu.utilization > 90%）只是观测工具，它们不会自动限流或重调度。你看到某个分片 CPU 持续 95%，系统不会主动降权或迁移 chunk —— 这需要人工干预或配合自定义脚本触发 sh.moveChunk()。
更关键的是：MongoDB 的 WiredTiger 缓存（wiredTiger.cacheSizeGB）是进程级全局配置，无法按租户切分。一个租户刷热数据可能挤掉另一个租户的缓存页，这是多租户共用分片时最隐蔽的性能干扰源。
真正做租户级 CPU 隔离，得在 mongod 进程之外划界——要么 OS 层硬限，要么 K8s 层硬限，要么物理/虚拟机层面分拆。MongoDB 6.0 的分片 + zone 是逻辑路由工具，不是资源仲裁器。
