凌晨 2:40，香港机房的监控屏里一条红线从 2ms 抬头到 40ms——就是它，P95 I/O 延迟在夜间批作业窗口里抬杠。我把咖啡杯放在机柜门上，手还没松开，就决定今晚把容器层存储 ‘掀开看个明白’。这篇文章，是那一夜到第二天上午我在香港机房里做的完整实操、踩坑与复盘。

目标与适用场景

环境：香港机房，Debian 11（bullseye，内核 5.10.x），Docker or containerd 容器运行时

问题：容器高密度（200–600 容器/宿主）下，小文件随机写、镜像层深、频繁 rename/copy-on-write 导致 P95/P99 I/O 延迟抬头

目标：用 OverlayFS（overlay2/overlayfs snapshotter） 优化容器层存储，降低延迟、提升并发

我现场的硬件与拓扑

我最初把镜像层放在 ext4 上也跑得动，但在目录重定向/rename 和多层合并目录上，XFS + ftype=1 的表现更稳定，后续也更好调参。

基线与问题画像

我先做了三件事确定“问题画像”：

采样命令

iostat -x 1
pidstat -dl 1
docker system df -v | head
find /var/lib/docker/overlay2 -xdev -type f | wc -l
cat /proc/meminfo | egrep 'Dirty|Writeback'

fio 基线（裸盘，不走 overlay）

fio --name=rand4k --filename=/data/testfile --size=8G \
    --ioengine=libaio --bs=4k --iodepth=64 --rw=randrw --rwmixread=70 \
    --direct=1 --numjobs=8 --runtime=120 --group_reporting

容器内 fio（走 overlay2）

docker run --rm -it --name fio \
  --mount type=bind,src=/data,dst=/data \
  alpine:3.19 sh -c "apk add --no-cache fio && fio <同上参数>"

现场观测（截取关键数）

注：数据为我的机型/镜像谱系下的实测样例，用于量级参考。你的镜像大小、层数、写入模式不同，数值会有差异，但趋势应一致。

关键原理（用运维人的话讲白）

OverlayFS：把只读镜像层（lowerdir）与可写层（upperdir）叠在一起形成一个合成视图（merged）；写时复制（COW）只复制被写的文件；删除通过 whiteout 标记。

overlay2 驱动：在 Docker/containerd 里对 OverlayFS 的实现，支持多 lowerdir 合并；新内核支持 redirect_dir=on、metacopy=on 这类元数据优化。

痛点来源：

• 层数多 + 小文件多 → dentry/inode 查找放大；
• rename/mkdir 频繁 → metadata 写放大；
• COW 复制大文件 → 瞬时写放大；
• 文件系统不支持 d_type/ftype=1 → hash/目录项行为退化甚至报错。

步骤一：文件系统与挂载准备（XFS ftype=1）

1. 创建 RAID1（NVMe）

mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/nvme0n1 /dev/nvme1n1
mkfs.xfs -m reflink=1,crc=1 -n ftype=1 /dev/md0
mkdir -p /var/lib/containerd /var/lib/docker
echo '/dev/md0 /var/lib/docker xfs defaults,noatime,inode64,logbufs=8,logbsize=256k,discard=async 0 0' >> /etc/fstab
echo '/dev/md0 /var/lib/containerd xfs defaults,noatime,inode64,logbufs=8,logbsize=256k,discard=async 0 0' >> /etc/fstab
mount -a

核对 ftype：

xfs_info /var/lib/docker | grep ftype
# ftype=1 即 OK

为什么不用 ext4？ ext4 也可（需支持 d_type），但在我这个场景，XFS 对 overlay2 的目录行为、并发下日志子系统表现更稳。你若已有 ext4 且 d_type=1，同样能做后续优化。

步骤二：内核与系统参数（Debian 11）

1. I/O 调度器与队列

NVMe 默认就是 none（多队列）。确认：

cat /sys/block/nvme0n1/queue/scheduler
# [none]
cat /sys/block/nvme0n1/queue/nr_requests   # 128/256

如批量场景 IOPS 顶高可适度调大 nr_requests=512（注意与控制器队列深度匹配）：

echo 512 > /sys/block/nvme0n1/queue/nr_requests

2. VM 与 inode/dentry cache

/etc/sysctl.d/99-overlayfs-tuning.conf：

vm.dirty_ratio=10
vm.dirty_background_ratio=5
vm.vfs_cache_pressure=50
fs.inotify.max_user_instances=2048
fs.inotify.max_user_watches=1048576
fs.file-max=2097152

生效：

sysctl --system

3. fstrim（异步 TRIM）

systemctl enable fstrim.timer
systemctl start fstrim.timer

步骤三：Docker 与 containerd 的 overlay2/overlayfs 配置

方案 A：Docker（我最终线上选它）

/etc/docker/daemon.json：

{
  "data-root": "/var/lib/docker",
  "storage-driver": "overlay2",
  "storage-opts": [
    "overlay2.override_kernel_check=true",
    "overlay2.size=80G"
  ],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "5"
  },
  "experimental": true,
  "registry-mirrors": ["https://<your-mirror>"],
  "features": { "buildkit": true },
  "exec-opts": ["native.cgroupdriver=systemd"]
}

overlay2.size 为可选的写层配额（每容器上限），避免“少数容器写爆盘”。

重启：

systemctl daemon-reload
systemctl enable docker --now
docker info | egrep 'Storage Driver|Backing Filesystem'

加速 rename/元数据路径（需要较新的内核支持）：

在 Docker 上无法直接写 redirect_dir/metacopy 挂载参数，但升级内核后 overlay2 会自动启用合适的特性。观察：

grep ^overlay /proc/filesystems
# 有 overlay 即内核支持

方案 B：containerd（overlayfs snapshotter）

生成默认配置：

containerd config default > /etc/containerd/config.toml

关键修改：

[plugins."io.containerd.snapshotter.v1.overlayfs"]
  mount_options = ["nodev","fsync=0","redirect_dir=on","metacopy=on","xino=on"]
[plugins."io.containerd.grpc.v1.cri".containerd]
  snapshotter = "overlayfs"
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
  SystemdCgroup = true

重启：

systemctl enable containerd --now
ctr plugin ls | grep snapshotter

注：fsync=0 在极端崩溃时可能丢最近元数据，务必评估业务容忍度；保守可以不加，或仅在批处理临时节点启用。

步骤四：镜像层“减肥”与层次重构（效果常常 > 任何 sysctl）

从基础镜像开始瘦身：使用 distroless/alpine 替代 ubuntu；去掉包缓存与编译产物。

减少层数：合并 RUN 指令；或在 BuildKit 下使用 --mount=type=cache。

避免小文件风暴：把大量小配置聚合打包（例如将 10k 个模板合并为压缩包，容器启动再解）。

可控的 squash：

Docker：--squash（需 experimental）

BuildKit：RUN --mount=type=cache,target=/root/.cache ...

示例（Node.js）：

# syntax=docker/dockerfile:1.7
FROM node:20-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN --mount=type=cache,target=/root/.npm \
    npm ci

FROM node:20-alpine AS build
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build

FROM gcr.io/distroless/nodejs20
WORKDIR /app
COPY --from=build /app/dist ./dist
USER 10001
CMD ["dist/server.js"]

步骤五：OverlayFS 行为验证（手工挂载理解 COW）

为了让新同事也“看见” overlay 的动作，我在一台测试机手挂了层：

mkdir -p /mnt/lower /mnt/upper /mnt/work /mnt/merged
echo "v1" > /mnt/lower/a.txt
mount -t overlay overlay -o lowerdir=/mnt/lower,upperdir=/mnt/upper,workdir=/mnt/work /mnt/merged

cat /mnt/merged/a.txt     # v1
echo "v2" > /mnt/merged/a.txt
cat /mnt/upper/a.txt      # v2 （COW 复制 + 修改）
rm /mnt/merged/a.txt
ls -la /mnt/upper | grep whiteout

现场讲清楚 lower/upper/work/merged 的关系后，大家对“写时复制”和“白化”就直观了。

步骤六：监控与基准

1. 容器侧 I/O 指标采集

• node_exporter：磁盘延迟、iowait
• cadvisor：per-container fs 读写字节
• 日志：集中在系统盘，避免和 overlay 上层抢写

2. 我用的两个 fio 场景

小块随机：

fio --name=rand4k --filename=/var/lib/docker/fiofile --size=16G \
    --ioengine=libaio --bs=4k --iodepth=128 --rw=randrw --rwmixread=60 \
    --direct=1 --numjobs=16 --runtime=180 --group_reporting

顺序写（镜像导入窗口）：

fio --name=seq128k --filename=/var/lib/docker/fiofile --size=32G \
    --ioengine=libaio --bs=128k --iodepth=64 --rw=write \
    --direct=1 --numjobs=4 --runtime=120 --group_reporting

运行维护（Runbook）

1. 垃圾回收

Docker（每晚 3 点）：

cat >/etc/systemd/system/docker-prune.timer <<'T'
[Unit]
Description=Docker prune timer

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target
T
cat >/etc/systemd/system/docker-prune.service <<'S'
[Unit]
Description=Docker prune service

[Service]
Type=oneshot
ExecStart=/usr/bin/docker system prune -af --volumes

[Install]
WantedBy=multi-user.target
S
systemctl enable --now docker-prune.timer

containerd：

cat >/etc/systemd/system/containerd-gc.service <<'S'
[Unit]
Description=containerd garbage collect

[Service]
Type=oneshot
ExecStart=/usr/bin/ctr --namespace k8s.io content gc --all
S

2. 定期层健康检查

df -ih /var/lib/docker
find /var/lib/docker/overlay2 -type d -maxdepth 1 | wc -l
docker image ls --format '{{.Repository}}:{{.Tag}}\t{{.Size}}' | sort -k2 -h | tail

3. 日志与 IO 隔离

容器 stdout 重定向或限制 json-file（上面已设 max-size）

噪声大的应用日志落到 系统盘 或独立分区

我踩过的坑（以及怎么爬出来）

XFS ftype=0 导致 overlay2 报错

症状：容器启动报 overlayfs:... not supported 或不可预期行为

解决：重建 XFS 并确保 ftype=1。这是“一票否决项”。

workdir/upperdir 不在同一文件系统

症状：invalid argument

解决：确保 upperdir 与 workdir 共用一个挂载点。

层太多导致 “too many lowerdir”/符号链接过深

解决：合并层、使用 BuildKit、适度 --squash，或在 CI 里做镜像“整形”。

inode 耗尽（不是空间满，而是 i 节点没了）

症状：No space left on device 但 df -h 还很空

解决：df -ih 查看 inode；改用更大 inode 密度的文件系统或把小文件聚合。

rename 重压下的元数据写放大

解决：升级到支持 redirect_dir=on 的内核/overlay；containerd 可显式传 redirect_dir=on；或业务层减少频繁跨目录移动。

fsync 风险权衡

开了 fsync=0 的节点要有清晰的“可丢最近元数据”的认知与补偿（任务幂等、可重放）。

混合负载抢盘

容器层与数据库落同一阵地时，数据库 fsync 会让 overlay 延迟抬头。

解决：物理隔离 或 cgroup I/O 限流（blkio/io.max），或数据库上独立 NVMe。

现场前后对比数据（节选）

容器启动 300 个（同镜像）

夜间批作业窗口（01:30–03:30）

进阶：cgroup v2 与 I/O 隔离（可选）

Debian 11 可切 v2（注意与运行时版本匹配）：

# /etc/default/grub
GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=1"
update-grub && reboot

随后用 io.max/io.weight 对写多的批作业容器限速，避免拖累全场（需要内核支持与运行时接线，K8s 下可通过 blkio/CSI 等方案）。

一张“做完就贴墙上”的清单

1.  XFS ftype=1，noatime, inode64, discard=async
2.  Docker overlay2 / containerd overlayfs snapshotter
3.  （可选）redirect_dir=on, metacopy=on, xino=on
4.  sysctl：dirty_ratio、inotify/file-max、vfs_cache_pressure
5.  镜像层瘦身、层数收敛、BuildKit cache
6.  日志与容器写层隔离，定期 prune/GC
7.  fstrim.timer 开启
8.  监控：延迟 P95/P99、inode、脏页、队列深度

FAQ（我被同事追问最多的三件事）

overlay2 会不会比直写裸盘慢？
会有 轻微 开销（元数据/合并视图），但在“镜像层优化 + XFS ftype=1 + 正确挂载 + 充足 page cache”后，对业务 P95 的改善常常远大于 overlay2 自身的开销。

ext4 和 xfs 选哪个？
都行。优先保证 d_type/ftype=1。我的场景里 xfs 在 rename/多层目录下表现更稳（度量与经验偏好）。

metacopy/redirect_dir 有坑吗？
老内核特性不完善或 bugfix 不足。Debian 11 的 5.10 系列总体 OK，但强烈建议先在灰度节点验证；containerd 能显式传挂载参数，Docker 更“黑盒”一点。

“把最后一台节点的 daemon.json 改完，监控面板上的红线像退潮一样平了下来。机房外面天色发白，我拍了一张 P95 曲线的截图发到群里，简单写了两句变更记录。第二天同事进来，我把那块写有 ftype=1 的便笺贴到了机柜门里侧。没人会记住是谁做的这件小事，但晚高峰时不再顶格的 iowait，会一直记得我们为它做过的事。”

附录：关键命令与模板

检查 d_type（ext4）

tune2fs -l /dev/sdxY | grep 'Filesystem features' | grep -q 'filetype' && echo OK

快速回滚（出问题时）

systemctl stop docker containerd
mv /etc/docker/daemon.json /etc/docker/daemon.json.bak.$(date +%s)
# 或恢复旧 config.toml
systemctl start docker containerd

导出镜像体检

docker image inspect REPO:TAG \
  --format '{{.RepoTags}} {{.GraphDriver.Data.UpperDir}} {{.RootFS.Layers}}'

一键体检脚本（节选）

#!/usr/bin/env bash
set -e
echo "FS:"; xfs_info /var/lib/docker | egrep 'ftype|sectsize|sunit'
echo "Inode:"; df -ih /var/lib/docker
echo "Dirty:"; egrep 'Dirty|Writeback' /proc/meminfo
echo "I/O queue:"; cat /sys/block/$(basename $(readlink /dev/md0))/queue/nr_requests
echo "Overlay count:"; find /var/lib/docker/overlay2 -maxdepth 1 -type d | wc -l

如果你也在香港或其他节点的 Debian 11 上被夜间 I/O 延迟“叫醒”，就按上面这套顺序来一遍：先文件系统（ftype=1），再运行时（overlay2/overlayfs），再镜像层（减肥），最后用数据说话。
有任何细节想深挖（比如 containerd + stargz 的冷启动优化，或 overlay2 与 ZFS/btrfs 共存策略），告诉我，我把我后来做的灰度结果也补上来