鲲鹏 ARM64 云主机 Ubuntu 24.04 容器化部署与低内存调优实践

在小规格 ARM64 云主机（如 2 核 512MB 至 2GB 内存的轻量实例）上运行 Ubuntu 24.04 并部署容器服务时，默认系统配置往往针对充裕内存设计，容易在拉取镜像或流量突发时触发 OOM Killer。本文记录一套经过实测的低内存调优与容器精简方案。

一、内核内存与 Swap 策略调优

在 512MB 至 1GB 物理内存机器上，完全关闭 Swap 会导致峰值进程直接被内核终止，而默认 swappiness=60 又会引发频繁磁盘换页拖慢响应。实测较稳妥的组合是配置 1GB 的 zram 或本地 swapfile，并将 vm.swappiness 下调至 15 到 20，同时将 vm.vfs_cache_pressure 保持在 100，让内核仅在物理内存真正吃紧时才动用交换空间。

二、精简 Ubuntu 24.04 常驻后台服务

Ubuntu 24.04 Server 默认启动了 snapd、multipathd、unattended-upgrades 以及 modemmanager 等后台守护进程。在纯云主机场景下，snapd 与 multipathd 常驻往往占用 60MB 到 100MB 物理内存。若业务不依赖 Snap 包，停用并屏蔽无关守护进程后，系统空载可用内存可立即释放约 20%。

此外，systemd-journald 默认会将日志缓存在内存与磁盘中，建议在 journald.conf 中显式设置 SystemMaxUse=50M 与 RuntimeMaxUse=16M，既避免小容量系统盘被历史日志写满，也减少内存映射开销。

三、ARM64 架构下的容器运行时选型

在 aarch64 环境下，Docker 守护进程本身（dockerd 加 containerd）常驻内存约 90MB 左右。如果只是运行单机无状态网络服务或反向代理，优先考虑两个方向：其一是使用 Podman rootless 模式，按需拉起容器且无常驻 daemon 开销；其二是直接采用静态编译的 linux-arm64 二进制配合 systemd unit 托管，通过 MemoryMax 与 MemoryHigh 实现与容器等价的 cgroup v2 资源隔离。

四、跨架构镜像拉取注意事项

在鲲鹏 ARM64 节点部署开源项目时，需先用 docker manifest inspect 确认上游镜像是否包含 linux/arm64 架构层。切勿在低内存机器上依赖 qemu-user-static 模拟运行 amd64 镜像，二进制转译不仅带来显著 CPU 损耗，还会额外放大数倍内存占用。对于仅提供源码的项目，建议在本地或 CI 中通过 buildx 交叉构建 arm64 制品后再推送上线。

五、总结

小规格云主机的核心瓶颈通常不在算力而在内存水位管理。通过裁剪无关守护进程、配置合理的 zram 与 Swap 阈值、限制日志体积并坚持原生 arm64 二进制或无守护容器部署，入门规格实例同样能长期稳定承载轻量级线上服务。