docker重启策略长期影响宿主机资源的关键在于是否诱发“失败-重启-再失败”循环：always/unless-stopped易放大内存泄漏、日志堆积、iptables碎片和exited容器残留，而on-failure:3可限频止损，no策略最利于根因定位。
评估 docker 重启策略对宿主机硬件资源的长期影响，关键不是看“重启动作本身耗多少 cpu”，而是看它是否掩盖、放大或诱发持续性资源压力——比如内存泄漏反复触发 oom、磁盘日志无节制堆积、iptables 规则碎片化、或僵尸 exited 容器缓慢填满存储。
看策略是否助长“失败-重启-再失败”循环
像 always 或 unless-stopped 这类无条件重启策略，一旦容器因内存泄漏、配置错误或依赖缺失而启动即崩溃（退出码 1、137、143），就会陷入高频启停：
- 每次启动都重新加载镜像层、初始化网络栈、挂载卷，增加 I/O 和 CPU 调度开销
- 若使用
-p端口映射，每次启停都会增删 iptables 规则，规则链膨胀后拖慢所有网络包转发 - 频繁创建/销毁容器进程，加剧内核调度和 cgroup 管理负担，尤其在高密度部署时
查被忽略的“静默残留”资源占用
重启策略不清理资源，只管拉起新实例。长期运行下容易积累三类隐性负载：
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
-
exited 容器残留：
docker ps -a中大量Exited (137)容器未清理，其可写层持续占用磁盘空间，/var/lib/docker/overlay2可能缓慢撑爆 -
日志文件失控：默认
json-file日志驱动不限大小，重启越频繁，日志轮转越跟不上，/var/lib/docker/containers/**/xxx-json.log单个达数 GB 很常见 -
网络规则泄漏：
sudo iptables -t nat -L DOCKER --line-numbers | wc -l若超过 200 条且持续增长，说明 bridge 模式 + 频繁重启已造成 NAT 表性能瓶颈
比对不同策略的实际资源行为差异
同一应用在不同重启策略下，宿主机长期负载表现可能截然不同：
- no：最“干净”，失败即停，便于定位根因；但需人工干预，不适合生产服务
- on-failure:3：最多重试 3 次，失败后彻底停止，既防偶发抖动，又避免无限循环；推荐用于批处理或有明确失败边界的任务
- always：最危险——只要容器退出就立刻重试，极易把单次故障演变成资源雪崩，尤其搭配未设内存 limit 的容器时
- unless-stopped：比 always 稍可控（手动 stop 后不再拉起），但仍无法阻止启动阶段就崩溃的容器反复冲击系统
用监控数据验证策略真实影响
别只看容器状态，要结合宿主机指标交叉判断：
- 执行
free -h，观察 available 值是否随重启频率升高而持续走低（说明 OOM 风险在累积） - 运行
df -h /var/lib/docker，确认磁盘使用率是否呈阶梯式上升（exited 容器或日志未清理） - 用
docker stats --no-stream --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemPerc}}\t{{.Status}}"找出那些“刚起来就退出”的容器，它们是策略失当的直接证据 - 检查
dmesg -T | grep "Killed process"是否与容器重启时间戳高度吻合——如果是，说明 restart 策略正在掩盖 OOM 根因
