cgroups机制通过限制、记录和隔离进程组资源实现容器化应用的资源控制；推荐使用cgroups v2统一层级，Docker用--memory和--cpus参数自动配置，Kubernetes在Pod中定义resources.limits，手动操作仅适用于调试。
Linux 系统中为容器化进程设置独立资源配额限制，核心是通过 cgroups（控制组）机制实现，而实际操作中应优先借助容器运行时（如 Docker）或编排系统（如 Kubernetes）的声明式接口，避免手动操作底层 cgroup 文件系统。
使用 Docker 设置容器资源配额
Docker 在启动时自动创建并配置对应 cgroup，用户只需指定参数即可生效：
-
内存限制：用
--memory=200m设硬上限（如 200MB），超出时进程可能被 OOM killer 终止；搭配--memory-swap=200m可禁用交换，确保物理内存严格受限 -
CPU 限制：用
--cpus=0.5表示最多占用半个逻辑 CPU（即 50% 时间片），底层等价于 cgroup v2 的cpu.max = 50000 100000 -
文件描述符与进程数：通过
--ulimit nofile=1024:2048或--ulimit nproc=500控制，这些限制作用于容器内 init 进程及其子进程
使用 systemd-run 启动带配额的容器进程
若需绕过 Docker、直接运行单个容器化应用（如 Podman rootless 模式或调试场景），推荐用 systemd-run：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 命令示例：
systemd-run --scope -p MemoryMax=1G -p CPUQuota=75% podman run alpine sleep 300 - 优势在于自动启用 cgroup v2 控制器、处理子树委派、进程迁移边界，并在退出后自动清理 cgroup 目录
- 不适用于已运行的进程——cgroup 配额必须从进程启动时绑定，无法动态追加到任意现有 PID
验证配额是否真实生效
不能只看配置参数，要检查内核层面的实际状态：
- 查 cgroup 路径：
cat /proc/$(pidof your-container-process)/cgroup确认进程归属正确的 cgroup 子树 - 读内存限制：
cat /sys/fs/cgroup/memory/system.slice/your-service.scope/memory.max（v2）或cat /sys/fs/cgroup/memory/docker/xxx/memory.limit_in_bytes（v1） - 监控实时使用：
cat /sys/fs/cgroup/memory/.../memory.current和cat /sys/fs/cgroup/cpu/.../cpu.stat中的nr_throttled字段可反映是否触发节流
注意事项与常见误区
几个关键细节决定配额是否真正可控：
- cgroup v2 是当前主流，务必确认系统启用的是 v2（
mount | grep cgroup2应有输出且挂载点为/sys/fs/cgroup） - 仅设
memory.max不等于“物理内存不超限”，需额外写memory.swap.max=0才禁用 swap - ulimit 类限制（如
nofile）作用于进程级，与 cgroup 的资源维度正交，两者应配合使用 - 容器引擎（Docker/K8s）会覆盖部分 systemd 默认值，修改
/etc/systemd/system.conf中的全局 Limit 并不会影响容器内进程，除非显式继承
