Docker Compose 内存泄漏问题分析与解决方案

问题概述

在Debian 12 (Bookworm)系统中，用户报告了Docker Compose 2.29.7版本存在内存泄漏问题。具体表现为dockerd进程初始占用约120MB内存，但在运行docker compose up -d命令后，内存使用量会随时间持续增长，几天内可能达到数GB，最终导致服务器内存耗尽。

技术背景

Docker Compose是用于定义和运行多容器Docker应用程序的工具。当使用docker compose up -d命令时，Compose会创建并启动所有定义的服务容器。正常情况下，Compose命令执行完成后应该不会持续占用内存资源。

问题现象

1. 初始状态：dockerd进程占用100-120MB内存
2. 运行docker compose up -d后，启动10个容器（总内存限制800MB）
3. 一天后：dockerd内存增长至约2GB
4. 两天后：dockerd内存增长至约4GB

问题根源

经过技术分析，该内存泄漏问题实际上与Docker引擎的网络子系统相关，特别是在使用用户自定义网络时会出现。当容器连接到用户自定义网络（这是Docker Compose的默认行为）并进行DNS查询时，会导致内存泄漏。

重现方法

可以通过以下命令重现问题：

cid=$(docker run --rm -d --network testnet --stop-signal SIGKILL busybox /bin/sh -c 'while [ 1 ]; do nslookup www.google.com; done'); sleep 120s; docker kill $cid

临时解决方案

1. 降级Docker Compose到2.26版本：

apt install docker-compose-plugin=2.26.1-1~debian.12~bookworm
apt-mark hold docker-compose-plugin
systemctl restart docker

2. 监控内存使用情况，定期重启dockerd服务

长期解决方案

由于问题根源在Docker引擎而非Compose本身，建议关注Docker引擎的后续更新。开发团队已在相关issue中跟踪此问题，预计会在未来的Docker引擎版本中修复。

最佳实践建议

1. 对生产环境中的Docker服务实施内存监控
2. 为容器设置合理的内存限制
3. 定期检查并更新Docker组件
4. 在非必要情况下，避免容器频繁进行DNS查询

总结

虽然此问题最初表现为Docker Compose相关，但实际上是Docker引擎在网络子系统中的内存管理问题。用户可以通过降级Compose版本作为临时解决方案，但最终需要等待Docker引擎的修复更新。对于关键业务系统，建议在测试环境中验证任何Docker版本更新后再部署到生产环境。