深夜 1:40，我在香港荃湾机房的冷风里打了个寒战。风从 2U 服务器的风道里穿过去，像在耳朵边持续吹口哨。监控墙上，CPU 负载和磁盘延迟此起彼伏。客户要把一批在线业务从混合云迁回香港自有机柜，目标是把 单台物理机容器密度从 180 提升到 300+，还要稳。那一刻，我知道这不是“装几台机器、起几个容器”那么简单，而是一次从 硬件→内核→存储→网络→调度 的全链条手术。下面是一整晚（其实是两周）的现场笔记与复盘。

目标与适用场景

目标：在 Ubuntu 22.04 + LXD 的体系下，提升容器密度与稳定资源利用率，降低抖动、减少尾延迟，兼顾网络吞吐与 I/O 隔离。

适用：香港机房或类似网络条件（跨境访问、双线/多线 BGP）、高密度系统容器（非 KVM 虚拟机） 场景；在线业务为主，混合 I/O（小文件、API、队列、轻量 DB 或缓存）为辅。

1. 现场硬件与基础环境

1.1 服务器与网络（实际交付批次）

1.2 OS 与内核

OS：Ubuntu Server 22.04.4 LTS（5.15 内核）

cgroup：v2 全量开启（LXD 对资源隔离更细）

LXD：Snap 安装，5.x LTS 通道（稳定、功能齐全）

文件系统：ZFS 承载 LXD 存储池（镜像池 lxdpool）

2. 系统层准备（内核与通用优化）

原则：先稳，再快；先限，再放。 资源天花板与保护阈值要先立起来。

2.1 基础包与工具

sudo apt update && sudo apt -y install zfsutils-linux nvme-cli numactl hwloc jq ethtool nvtop iotop
sudo snap install lxd --channel=5.21/stable

2.2 ZFS 池创建（镜像池）

# 假设 NVMe 盘为 /dev/nvme0n1 /dev/nvme1n1
sudo zpool create -o ashift=12 lxdpool mirror /dev/nvme0n1 /dev/nvme1n1
# 关键数据集参数（小文件/混合读写）
sudo zfs set compression=zstd lxdpool
sudo zfs set atime=off lxdpool
sudo zfs set recordsize=16k lxdpool             # 针对小块与日志型负载
sudo zfs set logbias=throughput lxdpool
sudo zfs set xattr=sa lxdpool

备注：recordsize=16k 在我们这批 API/队列/小 KV 的混合负载下明显降低写放大，日志型写入稳定许多。对纯静态资源可另建 recordsize=128k 的数据集。

2.3 网络与内核参数（/etc/sysctl.d/99-tuning.conf）

# TCP 队列与收发缓冲
net.core.somaxconn = 8192
net.core.netdev_max_backlog = 250000
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_tw_reuse = 1
net.ipv4.ip_local_port_range = 10000 65000

# Conntrack（NAT/大量短连接时）
net.netfilter.nf_conntrack_max = 524288

# 文件系统与监控器
fs.file-max = 2097152
fs.inotify.max_user_watches = 1048576
fs.inotify.max_user_instances = 8192

# 内存
vm.swappiness = 10
vm.dirty_ratio = 10
vm.dirty_background_ratio = 5
vm.max_map_count = 262144

sudo sysctl --system

2.4 Snap 自动刷新窗口（避免业务时段抖动）

sudo snap set system refresh.timer="sun2,4:00-6:00"   # 每周日 4-6 点刷新
sudo snap set system refresh.retain=2                 # 保留 2 个版本

3. LXD 初始化与存储/网络设计

3.1 lxd init 关键选择

sudo lxd init
# 选用 existing ZFS pool: lxdpool
# 网络：创建 lxdbr0，后续再接入生产 bridge/bond/vlan

3.2 网络拓扑与 MTU

lxdbr0：容器内部默认桥，MTU=1500（跨境路径碎片少，运营商环境更稳）

生产平面：br-prod 桥接到 25G 口，VLAN 隔离业务线

管理/备份：br-mgmt → 10G 口

# 调整 LXD 内置桥 MTU
lxc network set lxdbr0 bridge.mtu 1500
# 添加生产桥
ip link add name br-prod type bridge
ip link set br-prod up
ip link set ens2f0 up
ip link set ens2f0 master br-prod

坑 1｜MTU 抖动：某些路径如果中间段降 MTU 到 1492，会出现跨境偶发超时。统一 1500，业务端开启 PMTUD 后明显好转。

4. LXD 资源模型与 Profile 体系

高密度的关键是 “模板化”与“可移植的限额契约”。我们把容器按负载分 4 类：web、api、queue、db-lite，用 LXD Profile 固化。

4.1 通用基础 Profile（logging、limits 与安全）

# base.yml
config:
  limits.processes: "4096"
  limits.kernel.threads: "8192"
  limits.memory: 6GiB
  limits.memory.swap: "false"         # 避免 swap 惨案，必要时为单容器打开
  limits.cpu.priority: "5"            # 0~10，基线优先级
  security.nesting: "false"
  security.privileged: "false"
  environment.JOURNAL_STREAM: "9:9"
description: "Base limits & sane defaults"
devices:
  root:
    path: /
    pool: lxdpool
    size: 20GiB                        # rootfs 配额，防止日志撑爆
    type: disk
  eth0:
    name: eth0
    network: lxdbr0
    type: nic
name: base

4.2 CPU 亲和与 NUMA 感知

EPYC 7452 有 2 个 NUMA 节点（假设节点 0：CPU 0–15，节点 1：CPU 16–31）。

我们将网络敏感型 web/api 绑定在 同一 NUMA，减少跨节点 L3/内存穿越。

# web.yml
config:
  limits.cpu: "0-7"              # 绑在 NUMA0 的一半核心
  limits.memory: 4GiB
  limits.memory.swap: "false"
description: "Web tier - latency first"
name: web

# api.yml
config:
  limits.cpu: "8-15"             # NUMA0 另一半
  limits.memory: 6GiB
  limits.memory.swap: "false"
description: "API tier - mixed I/O"
name: api

# queue.yml
config:
  limits.cpu: "16-23"            # 转到 NUMA1
  limits.memory: 8GiB
  limits.memory.swap: "false"
description: "Queue/Worker - CPU burst"
name: queue

# db-lite.yml
config:
  limits.cpu: "24-31"            # NUMA1 的后半
  limits.memory: 12GiB           # 轻量 DB/缓存
  limits.memory.swap: "false"
description: "Lightweight DB/Cache"
devices:
  root:
    path: /
    pool: lxdpool
    size: 60GiB                  # 给 DB 多点盘
    type: disk
name: db-lite

技巧：limits.cpu 既可写数量 4，也可写 CPU 列表/区间（如 0-7,^3）。明确列出有助于 NUMA 局部性。

4.3 网络限速（“邻里和睦”）

对突发带宽的队列/批处理做轻限速，避免抢走“前台”：

lxc config device set c-queue eth0 limits.ingress=800Mbit limits.egress=800Mbit

5. 镜像、缓存与启动时延

5.1 本地镜像缓存

先把常用基础镜像拉到本地，避免跨境/跨站抖动。

lxc image copy images:ubuntu/22.04 local: --alias u2204

5.2 从 Profile 起容器（秒级交付）

lxc launch u2204 c-web-01 -p base -p web
lxc launch u2204 c-api-01 -p base -p api
lxc launch u2204 c-queue-01 -p base -p queue
lxc launch u2204 c-db-01 -p base -p db-lite

6. ZFS 与 I/O 隔离的“可落地做法”

容器 I/O 抖动，是高密度环境最常见的“邻里纠纷”。

6.1 数据集分层

LXD 会为每个容器创建 lxdpool/containers/<name> 数据集。

对 写多的容器，单独微调：

sudo zfs set recordsize=16k lxdpool/containers/c-api-01
sudo zfs set primarycache=all lxdpool/containers/c-api-01

6.2 日志落地与回卷

统一把容器内 /var/log 做 logrotate，避免 rootfs 配额打满。

生产遇见 日志暴走 时的临时止血：

lxc exec c-api-01 -- bash -c 'find /var/log -type f -name "*.log" -size +200M -delete'
lxc config set c-api-01 limits.memory.swap true     # 临时兜底，压住 OOM

坑 2｜OOM 误杀：Ubuntu 22.04 的 systemd-oomd 在宿主机触发时也可能影响容器。我们将关键前台容器提高 OOM 分值（容器内）或干脆禁用宿主的 oomd，改用 cgroup 限额 + 监控告警托底。

7. 网络：桥接、VLAN、直连与防火墙

7.1 选择策略

低延迟/高吞吐：bridged 到 br-prod，容器直接二层接入，方便做 VLAN。

简单隔离/默认：lxdbr0 NAT 出口，配合合适的 conntrack 与 SNAT。

7.2 LXD 直桥示例（上生产平面）

lxc network attach br-prod c-web-01 eth1 eth1
lxc config device set c-web-01 eth1 nictype=bridged
# 如需指定 VLAN
lxc config device set c-web-01 eth1 vlan=120

坑 3｜nftables/iptables 冲突：同机装 Docker 时，iptables-legacy 与 nft 冲突可能导致 NAT 异常。保持 nft 体系一致，避免混搭。

8. 调度与密度：配额表与实际观测

8.1 我们的“配额表”基线（单机）

注：共享 CPU 下，利用率才是关键。通过限速、配额与 NUMA 亲和，降低资源争抢的“尖峰”。

8.2 优化前后关键指标（实测）

指标    优化前（180 容器）    优化后（280 容器）    说明
平均 CPU 利用率    55–65%    68–78%    NUMA 亲和 + 优先级控制
99 线 API 延迟    120–180 ms    85–120 ms    MTU 统一 + lxdbr0 调优
NVMe 写放大（估算）    高    中    recordsize=16k + zstd
容器 OOM 事件/周    6–10    0–2    swap 策略 + 限额
网络丢包（跨境）    偶发    稳定    conntrack+PMTUD

9. 监控与告警（别等火烧眉毛）

LXD Metrics：lxd metrics 原生 Prometheus 端点，采集容器级 CPU/内存/网卡。

节点侧：node_exporter、zfs_exporter、nvme-cli 定时采集 SMART。

自检脚本：定时扫 rootfs 使用率、错误日志大小前 20、最近 OOM 记录。

# 快速扫容器磁盘使用（GB）
for c in $(lxc list -c n --format csv); do
  size=$(lxc exec "$c" -- df -BG --output=used,/ | awk 'NR==2{print $1}')
  echo "$c,$size"
done

10. 常见坑位与现场解法

容器时间漂移/时区混乱

解法：宿主启用 chrony；容器统一 TZ=Asia/Hong_Kong，写入 profile environment.TZ。

大规模创建容器时网络 DHCP 抖动

解法：对批量启动的容器预分配静态 IP（bridged + ipv4.address），或延迟 50–100 ms 起容器。

日志撑爆 rootfs

解法：Profile 固定 size 配额 + 容器内 logrotate；LXD 侧一键回收脚本。

镜像拉取慢/失败

解法：本地镜像缓存 + 离线导入；做好镜像签名与版本别名（u2204@YYYYMMDD）。

CRIU 迁移并不总是灵（有些进程特性不支持）

解法：业务窗口迁移，或旁路同步配置，增量上线；CRIU 仅用于能稳定通过的类型。

11. 批量化与声明式：把“经验”固化为“按钮”

11.1 批量创建与标记

for i in $(seq -w 1 80); do
  lxc launch u2204 c-api-$i -p base -p api
  lxc config set c-api-$i user.app "api"
  lxc config set c-api-$i user.batch "migrate-202508"
done

11.2 生命周期与金丝雀

新 profile → 先起 5% 金丝雀 → 观察 24 小时 → 全量迁移。

变更内容：只调参数不改大结构，配合“回滚”脚本（保存旧 profile）。

12. 安全与隔离

默认非特权容器（security.privileged: false），避免 root 穿透。

ID 映射（subuid/subgid）保持默认自动映射即可；需要特权能力的个别容器单独开。

宿主层防火墙基于 nftables，只开业务必要出入站；容器到容器走 VLAN/ACL。

13. 一套可直接复用的落地清单（Checklist）

•  NVMe → ZFS mirror，zstd、recordsize=16k、atime=off
•  sysctl：somaxconn、nf_conntrack_max、inotify、vm.*
•  LXD：Snap 刷新窗口设定；本地镜像缓存
•  Profile：base + {web,api,queue,db-lite}（CPU 亲和、内存限额、rootfs 配额）
•  网络：br-prod、统一 MTU=1500、按需 VLAN、批处理限速
•  监控：LXD metrics + node/zfs exporter，日志与磁盘前 20 报表
•  运维：金丝雀 5%，回滚脚本与 CRIU 试点

清晨 6:20，港岛那边天边泛起一条鱼肚白。最后一批队列容器起完，我把耳机摘下，听到机房里风扇仍旧稳定地呼啸。仪表盘上的曲线变得好看：CPU 的峰谷更有节奏，I/O 延迟不再“锯齿”，跨境的红点也少了。
我知道这不是“某个玄学参数”救了我们，而是 从硬件、内核、存储、网络到 LXD 调度的系统化约束与取舍。高密度不是把密度调到“最大”的勇气，而是把“系统稳定运转的边界”看得足够清楚的克制。
如果你也在香港的机房里和我一样吹过那股风，希望这篇记录能让你下一次在曲线面前，笑得更早一点。

附：关键命令速查

# 查看 NUMA/CPU 拓扑
lscpu --extended
numactl --hardware

# LXD 常用
lxc profile list
lxc profile show base
lxc list -c ns46t                                       # 名称/状态/IPv4/内存/类型
lxc config show c-api-01 --expanded
lxc exec c-api-01 -- systemctl status your-service

# ZFS 快照与回滚
zfs snapshot lxdpool/containers/c-api-01@pre-upgrade
zfs rollback lxdpool/containers/c-api-01@pre-upgrade

# 网络速率限制（容器网卡）
lxc config device set c-queue-01 eth0 limits.ingress=800Mbit limits.egress=800Mbit

写到这里，我关了笔记本，把手心摊在空调出风口前“烤”了一会儿。每一次把密度做上去、把尾延迟压下去，都是对“工程纪律”的一次致敬。愿你也有一次“稳稳的”清晨。