Docker Engine优化需围绕负载、资源与稳定性针对性调参：内存上强制容器限制并启用cgroup v2；CPU上设配额与绑核；存储用overlay2并限层数和磁盘；守护进程需内存限制与日志轮转。
调整 Docker Engine 守护进程（dockerd）的配置参数，不是简单堆叠数值，而是围绕实际负载、资源约束和稳定性做针对性优化。关键在于理解每个参数的作用边界，避免“调参即万能”的误区。
内存与 OOM 风险控制
Docker 默认不限制容器内存使用上限，宿主机内存耗尽时内核会触发 OOM Killer，可能误杀关键进程。必须显式设置内存限制策略：
-
全局默认内存限制：在
/etc/docker/daemon.json中添加"default-ulimits": {"memlock": {"Hard": -1, "Soft": -1}}不解决根本问题；更有效的是通过"default-runtime": "runc"+ 容器级--memory或docker-compose.yml中的mem_limit强制约束 -
启用 memory cgroup v2：确认宿主机已启用 cgroup v2（
cat /proc/filesystems | grep cgroup2），并在 dockerd 启动时加--cgroup-parent=/docker配合"cgroup-parent": "/docker"，提升内存回收精度 -
禁用 swap 使用：设
"experimental": false并确保"default-ulimits": {"as": {"Hard": 0, "Soft": 0}}不推荐；正确做法是关闭容器 swap：--memory-swap=0或在 daemon.json 中设"default-memory-swap": 0
CPU 调度与隔离优化
CPU 参数调优重点在于避免争抢和保障响应性，而非单纯提高配额：
-
避免 CPU 全占用陷阱：不设
--cpus时容器可跑满所有核，建议对非关键服务设上限，如--cpus="1.5"；生产环境推荐配合--cpu-quota和--cpu-period（如100000/50000表示 50% 核心时间） -
绑定物理核提升确定性：对延迟敏感服务（如实时日志处理），用
--cpuset-cpus="0-1"绑定专用核心，并关闭该范围内的 CPU 频率调节（echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor） -
禁用不必要的调度器特性：若未使用 Swarm 模式，可在 daemon.json 中设
"swarm-default-advertise-addr": ""和"cluster-store": ""，减少后台 goroutine 占用 CPU
存储驱动与镜像层性能
overlay2 是当前主流且稳定的存储驱动，但需规避常见瓶颈：
-
确保底层文件系统支持 d_type：XFS 推荐挂载参数
ftype=1，ext4 需mkfs.ext4 -O extended_attributes,large_file,filetype ...，否则 overlay2 无法正常工作 -
限制镜像层数与大小：单镜像超 100 层或总大小超 5GB 易引发构建/拉取卡顿；通过多阶段构建压缩层数，用
docker image prune -f定期清理悬空镜像 -
启用磁盘配额（仅 overlay2 + xfs）：在 daemon.json 中设
"storage-opts": ["overlay2.size=10G"]，为每个容器 rootfs 设置硬上限，防止单个容器写爆磁盘
守护进程自身资源与日志治理
dockerd 进程本身也需资源保护，尤其在高并发 pull/push 场景下：
-
限制守护进程内存用量：通过 systemd 管理 dockerd 时，在
/etc/systemd/system/docker.service.d/override.conf中添加：[Service]<br>MemoryLimit=2G<br>LimitNOFILE=1048576
-
收敛日志输出量：默认 json-file 日志无轮转，易占满磁盘；统一设为
"log-driver": "local"（轻量、自动压缩与过期），并配"log-opts": {"max-size": "10m", "max-file": "3"} -
关闭调试模式：确认
"debug": false（默认），避免日志中混入 trace 级输出拖慢响应；临时排查可用dockerd --debug，但切勿长期启用
