一次Linux的inode耗尽排查实录：Nginx Proxy Manager与微小文件灾难解决

结论先行：当系统频繁提示 No space left on device，但使用 df -h 检查却发现磁盘尚有数十吉字节（GB）空闲空间时，故障根因几乎百分之百是文件系统索引节点（Inode）被海量微小文件消耗殆尽。传统通过 rm -rf * 清理数百万小文件往往会触发 Argument list too long 错误。规范的抢救流程是：先用 df -i 确认 Inode 耗尽分区，通过递归统计算法定位目标目录，使用 find -type f -delete 或 rsync 快速释放 Inode，并在容器编排中限制临时缓存生成与日志轮转。

0、故障现场还原：明明还有空间，为什么无法创建文件？

某个普通的工作日上午，服务器监控突然发出连环警报：正在运行的 Docker 容器无法写入日志并连续退出崩溃，SSH 登录后尝试使用 Tab 键补全命令提示写入临时文件失败，尝试创建新文件时系统直接报错：

1
2
3

touch test.txt
# 报错信息：
# touch: cannot touch 'test.txt': No space left on device

第一反应是执行常规的磁盘容量检查：

df -h

输出结果却令人困惑：

1
2
3

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        50G   14G   34G  30% /
tmpfs           2.0G     0  2.0G   0% /dev/shm

根分区明明还有 34GB 的可用空间，使用率仅为 30%，为什么操作系统坚持声明“设备上没有空间”？

1、底层原理剖析：Inode 与 Data Block 的双重约束

在 Linux 的 Ext4 或 XFS 文件系统中，磁盘空间并不是铁板一块，而是划分为两个独立分配的结构：数据块（Data Block） 与 索引节点（Inode，Index Node）。

Data Block：用于存储文件的实际正文。默认一个块大小为 4KB。日常执行 df -h 看到的容量百分比，正是数据块的消耗情况。
Inode：用于存储文件的元数据（权限、用户组、文件大小、创建/修改时间戳、以及指向数据块的指针）。在格式化磁盘创建 Ext4 文件系统时，Inode 的总数量就已经被固定下来（通常约为每 16KB 磁盘容量分配一个 Inode）。

任何一个文件的创建，都必须同时成功申请到至少 1 个 Inode 和 1 个 Block。如果磁盘上存在数百万个只有几百字节甚至 0 字节的临时文件，数据块还剩余数十 GB，但 Inode 数量已经被吃满，文件系统就再也无法创建任何新文件或目录。

2、排错定位流程：抓出消耗数百万小文件的元凶

2.1 使用 `df -i` 检查 Inode 占用

执行检查索引节点占用命令：

df -i

输出瞬间锁定了故障真凶：

1
2
3

Filesystem       Inodes   IUsed   IFree IUse% Mounted on
/dev/vda1       3276800 3276798       2  100% /
tmpfs            512000       1  511999    1% /dev/shm

根分区总计拥有 327 万个 Inode，已使用 3276798 个，剩余仅有 2 个，使用率高达 100%！

2.2 递归排查小文件聚集目录

知道了根分区 Inode 耗尽，接下来需要定位到底是哪一个目录堆积了海量小文件。通过单行 Shell 脚本对根目录各子项进行递归统计：

# 统计根目录下各主要目录的文件数量
sudo find / -xdev -maxdepth 2 -type d -exec sh -c '
  for dir do
    count=$(find "$dir" -type f 2>/dev/null | wc -l)
    printf "%-8s %s\n" "$count" "$dir"
  done
' sh {} + | sort -n

若目录较深，可直接排查常见的高频碎文件温床目录：

/var/spool/postfix/maildrop 或 /var/spool/clientmqueue（未配置收件人导致的本地 cron 失败邮件堆积）
/tmp 与 /var/tmp（应用未清理的临时缓存）
/var/lib/docker/volumes 或 /var/lib/docker/overlay2（容器内部生成的临时文件）

在本次排查中，通过逐层缩进，最终锁定了路径：

find /var/lib/docker/volumes -maxdepth 3 -type d -exec sh -c '
  for d; do
    echo "$(find "$d" -maxdepth 2 -type f 2>/dev/null | wc -l) $d"
  done
' _ {} + | sort -nr | head -n 10

终端输出了触目惊心的数据：

1 2	2845192 /var/lib/docker/volumes/npm_data/_data/nginx/proxy_temp 321500 /var/lib/docker/volumes/npm_data/_data/logs

在 Docker 容器运行的 Nginx Proxy Manager (NPM) 数据卷目录下，proxy_temp 目录独揽了超过 280 万个碎小文件！

3、破案：Nginx Proxy Manager 为什么会制造数百万文件？

Nginx Proxy Manager 是一款深受开发者喜爱的反向代理图形化管理面板。但由于默认的配置模板倾向于兼顾通用性，其中包含如下代理参数：

1 2	proxy_buffering on; proxy_temp_path /data/nginx/proxy_temp;

当外部存在自动化扫描工具、大量爬虫抓取动态图片、或者慢速网络客户端请求较大体积的上游响应时，Nginx 会将上游尚未被客户端读取的数据先缓存在 proxy_temp 临时目录中。

在特定配置场景下：

客户端在下载完成前主动中断了 TCP 连接；
上游服务返回了带有特殊头信息的微小响应；
Nginx 未能按时触发自动垃圾回收，导致 proxy_temp 下层层嵌套的十六进制哈希子目录（如 /0/01/0000000100）积累了数以百万计的残存碎片文件，最终一举将宿主机的 327 万个 Inode 吞噬殆尽。

4、紧急救援：海量小文件的高效清理策略

在 Inode 耗尽时，常规的清理命令往往会直接瘫痪。必须掌握正确的清理手段。

4.1 避开 `Argument list too long` 陷阱

许多人习惯进入目录直接运行：

1 2	cd /var/lib/docker/volumes/npm_data/_data/nginx/proxy_temp rm -rf *

系统会立即报出错误：

1	-bash: /bin/rm: Argument list too long

这是因为 Linux 内核定义了传递给单个系统调用参数的最大内存空间（ARG_MAX，通常约 2MB）。当通配符 * 展开出来的文件名列表超过上限时，Bash 解释器会在执行前直接抛错。

4.2 清理方案 A：使用 `find -delete`（精准且安全）

find 的 -delete 参数会直接调用内部的 unlink 系统调用，无需通过命令行传递参数列表，速度极快：

# 针对临时文件目录直接删除所有普通文件
sudo find /var/lib/docker/volumes/npm_data/_data/nginx/proxy_temp -type f -delete

# 清理空目录
sudo find /var/lib/docker/volumes/npm_data/_data/nginx/proxy_temp -mindepth 1 -type d -empty -delete

4.3 清理方案 B：使用 `rsync` 快速置空（最强性能方案）

如果要清空的目录包含数百万级文件，find 的递归遍历依然需要消耗较多 CPU 和时间。利用 rsync 的目录同步机制比 rm -rf 性能快数倍：

# 1. 创建一个临时的空目录
mkdir /tmp/empty_dir

# 2. 通过 rsync 将目标目录快速同步为空
sudo rsync --delete-before -a -H -v --force /tmp/empty_dir/ /var/lib/docker/volumes/npm_data/_data/nginx/proxy_temp/

# 3. 移除临时空目录
rmdir /tmp/empty_dir

清理完毕后再次执行 df -i 检查：

df -i /

1 2	Filesystem Inodes IUsed IFree IUse% Mounted on /dev/vda1 3276800 421500 2855300 13% /

可用 Inode 瞬间释放出 285 万个，系统立即恢复正常，文件创建与容器启动全部重归通畅。

5、治本之策：杜绝 Inode 再次耗尽的防护规范

临时清理只能救急，必须通过架构与配置调整，阻断小文件的无节制膨胀。

5.1 调整 Nginx Proxy Manager 缓冲与缓存参数

如果主要代理的应用属于流式数据（如大文件下载、SSE 实时推送、WebSocket），建议针对对应的 Proxy Host 关闭不必要的磁盘缓冲，或者将其重定向至内存 tmpfs：

在 Nginx 对应虚拟主机的 Advanced 自定义配置段加入：

# 禁用代理磁盘缓冲（改用全内存流式直通）
proxy_buffering off;
proxy_request_buffering off;

# 或者指定最大临时文件上限，禁止写入超大临时碎文件
proxy_max_temp_file_size 0;

5.2 Docker 全局日志限制与卷管理

Docker 容器默认对 stdout / stderr 日志不设大小上限，容易在 /var/lib/docker/containers/ 目录下生成大量切割日志。在 /etc/docker/daemon.json 中配置日志轮转：

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "20m",
    "max-file": "3"
  }
}

重启 Docker 使配置生效：

1	sudo systemctl restart docker

5.3 编写定期清理定时任务

在 /etc/cron.daily/clean-proxy-temp 创建维护脚本，每日凌晨对临时目录中超过 2 天未访问的文件执行自动回收：

sudo tee /etc/cron.daily/clean-proxy-temp << 'EOF'
#!/bin/bash
TARGET_DIR="/var/lib/docker/volumes/npm_data/_data/nginx/proxy_temp"
if [ -d "$TARGET_DIR" ]; then
    find "$TARGET_DIR" -type f -mtime +2 -delete 2>/dev/null
    find "$TARGET_DIR" -mindepth 1 -type d -empty -delete 2>/dev/null
fi
EOF

sudo chmod +x /etc/cron.daily/clean-proxy-temp

6、结合系统健康巡检脚本建立预警

单纯依靠人工登录排查难以防患于未然。建议结合监控脚本对 Inode 和 Block 使用率进行双重检测。你可以参考开源工具箱 ittinker-scripts 中的 vps-health-monitor 模块：

# 下载系统健康体检监控脚本
sudo curl -fsSL https://raw.githubusercontent.com/Richardson/ittinker-scripts/main/vps-health-monitor/monitor.sh -o /usr/local/bin/vps-health-monitor
sudo chmod +x /usr/local/bin/vps-health-monitor

# 手动执行一次全面检测（包含 Inode 报警与僵尸进程统计）
/usr/local/bin/vps-health-monitor

脚本内部的核心 Inode 预警逻辑如下：

# 获取根分区 Inode 使用率整数值
INODE_USAGE=$(df -i / | awk 'NR==2 {print $5}' | tr -d '%')

if [ "$INODE_USAGE" -gt 85 ]; then
    echo "[CRITICAL] Inode usage is at ${INODE_USAGE}%! Sending alert..."
    # 调用 webhook 通知或发送邮件
fi