Agent容器资源限制CPU内存
Agent 容器在运行过程中如果不对 CPU 和内存做限制，可能会因为任务并发或代码异常把服务器资源吃满，导致整台机器卡死甚至其它服务被 OOM 杀掉。
本文以 Docker 环境为例，讲清楚如何通过 --cpus、--memory 和 compose 配置限制 Agent 容器的资源使用，并给出验证和排错方法，适合零基础运维直接照做。
先看当前 Agent 容器消耗了多少资源
在动手之前，先用 docker stats 观察正在运行的 Agent 容器：
docker stats --no-stream输出里的 CPU % 和 MEM USAGE / LIMIT 能直观反映容器当前占用。
如果 LIMIT 显示为无限大，说明容器没有资源约束，一旦 Agent 任务突发或内存泄漏，宿主机很容易被拖垮。
记录一下 Agent 容器名，后面配置会用到。
用 docker run 直接限制 CPU 和内存
如果 Agent 是用 docker run 启动的，可以在启动命令里追加两个参数：
docker run -d --name agent \
--cpus="1.5" \
--memory=2g \
--memory-swap=2g \
your-agent-image--cpus="1.5"表示容器最多使用 1.5 个 CPU 核心，支持小数。--memory=2g限定内存上限为 2GB。--memory-swap=2g表示不额外分配 swap，避免内存超限后继续用交换分区硬撑，这能更快触发 OOM 而不是让服务器持续卡顿。
如果 Agent 已经在运行，需要先停止并删除旧容器，再用新参数重建。
用 docker-compose 配置更便于维护
使用 compose 时，在服务定义下增加 deploy.resources 段：
services:
agent:
image: your-agent-image
container_name: agent
deploy:
resources:
limits:
cpus: "1.5"
memory: 2g
reservations:
cpus: "0.5"
memory: 512mlimits 是硬上限，reservations 是预留值，仅在 Swarm 模式下部分生效，本地 compose 主要看 limits。
修改后执行：
docker-compose up -d注意，使用 docker-compose 时需要确保版本支持 deploy 字段，普通 Docker Compose V2 可以直接使用。
验证限制是否真的生效
配置完成后，用两条命令确认：
docker inspect agent --format='{{.HostConfig.CpuShares}} {{.HostConfig.Memory}}'CpuShares 和 Memory 会显示底层配置。
更直观的是运行一段高负载任务后观察 docker stats：
docker exec agent stress-ng --cpu 4 --timeout 30s如果容器内有 stress-ng，执行后看 docker stats 的 CPU % 是否被限制在 150% 左右（对应 1.5 核）。
内存限制可以查看 docker inspect 中的 Memory 值，当容器超过内存上限时会被 OOM 杀掉，这是预期行为，日志里能看到 Killed 提示。
避坑说明：这些细节最容易出错
- 不要只设内存不加 swap 限制。只设
--memory时，默认--memory-swap等于两倍内存，容器仍可能占用较多 swap，表现为服务器变卡。建议显式设置--memory-swap与内存一致。 - CPU 限制是相对值而非绝对的“几核”。
--cpus在 Linux 上通过 CFS 配额实现，对单核频繁计算的任务有效，但如果 Agent 调用外部进程或 GPU，限制效果会减弱。 - Compose 文件中的
cpus是字符串，必须写成"1.5"而不能是数字1.5，否则部分版本解析报错。 - 限制内存后要关注容器重启策略。OOM 导致容器退出后，建议加上
restart: unless-stopped，避免 Agent 停掉后无法自愈。
如果你现在运行的 Agent 已经出现 CPU 占满或内存飙高，先用 docker stats 定位容器名，再按本文加限制重建即可。
如果文中命令在你这台机器上报错，优先检查 Docker 版本和 compose 文件缩进。
