1核2G的服务器运行Docker容器有哪些优化建议？-PHPWP博客

在 1 核 2G（1 vCPU, 2GB RAM）的服务器上运行 Docker 容器，资源非常紧张。任何配置不当都可能导致 OOM（内存溢出）杀死进程、Swap 频繁导致系统卡顿甚至服务不可用。

以下是针对该配置的核心优化建议，分为Docker 守护进程配置、容器资源限制、应用层优化和系统级调优四个维度：

这是最容易被忽视但影响最大的部分。默认配置往往是为多核大内存机器设计的。

调整 Docker 存储驱动：
- 确保使用 overlay2（现代 Linux 内核默认），避免使用 aufs 或 devicemapper，前者性能更好且更省内存。
- 检查 /etc/docker/daemon.json：
```
{
"storage-driver": "overlay2",
"log-driver": "json-file",
"log-opts": {
  "max-size": "10m",
  "max-file": "3"
}
}
```
  解释：限制日志大小防止磁盘写满，1G 内存的服务器一旦日志爆满会导致服务崩溃。
禁用不必要的插件和服务：
- 如果不需要构建镜像，可以关闭 docker build 相关功能或限制其资源。
- 移除不用的 Docker Compose 项目或停止未使用的容器，减少 dockerd 维护状态表的开销。

绝对不要让容器无限制地占用宿主机资源。必须在启动时显式指定限制。

内存限制 (Memory Limit)：
- 原则：2GB 总内存中，宿主机系统和 Docker 守护进程本身至少需要预留 200MB~400MB。留给容器的可用内存通常在 1.5GB ~ 1.8GB 之间。
- 操作：
```
# 示例：限制容器最大使用 1.2GB 内存，超出则被杀
docker run -m 1.2g --memory-swap=1.5g ...
```
  注意：--memory-swap 必须大于等于 --memory。如果设为 -1 表示无限制，但在 2G 机器上极度危险。
CPU 限制 (CPU Quota)：
- 1 核意味着 100% CPU 时间片。如果有多个容器，它们会争抢这 1 个核心。
- 操作：
```
# 限制容器最多使用 0.5 核 (50%)
docker run --cpus=0.5 ...

# 或者使用 CPU shares (权重)
docker run --cpu-shares=512 ... 
```
- 策略：如果是单容器部署，可以不设限制；如果是多容器，务必通过 --cpus 隔离，防止一个高负载任务拖垮整个系统。
禁止 Swap 交换（推荐）：
- 在 2G 内存下，一旦触发 Swap，I/O 延迟会剧增，系统几乎卡死。
- 操作：在 Docker 启动参数中加入 --oom-score-adj=0（降低被杀优先级，配合其他策略）或直接在宿主机层面关闭 Swap，强制应用处理内存不足时的优雅降级（虽然通常直接 OOM Kill 更快）。
- 建议：如果应用支持，设置 --memory-swappiness 为 0（仅在容器内有效，需内核支持），或者在宿主机 /etc/sysctl.conf 中设置 vm.swappiness=1。

容器只是载体，应用本身的效率决定了生死。

选择轻量级运行时：
- JVM 应用：必须调整 JVM 参数。默认堆内存可能过大。
```
java -Xms512m -Xmx768m -XX:+UseG1GC -jar app.jar
```
  原则：堆内存 + 非堆内存 < 容器 Memory Limit。
- Python/Go/Node.js：这些语言通常比 Java 更省内存，优先选用。
- Alpine 镜像：所有基础镜像尽量使用 alpine 版本（如 python:3.9-alpine, node:16-alpine），体积更小，启动更快，内存占用更低。
拒绝“胖”应用：
- 避免在容器中运行重型 GUI 程序、数据库（除非经过极致优化）、或同时运行 Web Server + DB + Cache。
- 拆分架构：如果必须运行多个服务，考虑将它们拆分成独立的微服务，每个分配极小的内存配额，利用 K8s 或 Docker Swarm 调度（如果单机无法调度，则只能串行运行或严格限制并发）。
缓存管理：
- 确保应用有合理的缓存清理机制。Redis 等缓存中间件在 2G 机器上风险极高，建议将 Redis 内存限制在 256MB 以内，并开启 LRU 淘汰策略。

关闭透明大页 (Transparent Huge Pages, THP)：
- THP 在低内存环境下可能导致严重的内存碎片和抖动。
- 操作：
```
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
```
  (可写入 rc.local 或 systemd 服务开机自启)

调整虚拟内存参数：

编辑 /etc/sysctl.conf：

vm.swappiness = 1       # 极低频率使用 Swap
vm.vfs_cache_pressure = 50 # 适度回收 inode/dentry 缓存，平衡内存

监控与告警：
- 安装轻量级监控工具（如 cAdvisor 或简单的 htop 脚本）。
- 重点监控 Available Memory 而非 Free Memory。
- 配置 systemd 的 OnFailure 动作，当容器因 OOM 退出时自动重启并记录日志。

最终建议：
在 1 核 2G 的环境下，“少即是多”。最好只运行一个核心业务容器。如果必须运行多个服务，请优先考虑将非核心服务迁移到云端或其他实例，或者对现有服务进行严格的代码级瘦身（例如去掉不必要的依赖库、优化算法复杂度）。