Nginx autoindex 列出大量文件时阻塞IO导致服务冻结的问题求助

朋友，你遇到的这个问题我之前也接触过类似场景，咱们一步步来拆解和解决：

首先得搞清楚为什么会出现整个服务冻结的情况：nginx的worker进程在处理autoindex请求时，是同步遍历目录下所有文件的——这属于阻塞式IO操作，尤其是你用的btrfs文件系统，当目录里有120多万个文件时，读取目录元数据的耗时会非常长。此时处理这个请求的worker进程被完全占用，没法响应其他虚拟主机的请求，就出现了你说的“全服务超时冻结”现象。

下面给你几个可行的解决方向，按优先级排序：

1. 给大目录单独做静态预生成的目录列表（最推荐） #

既然其他路径依赖autoindex的json输出，但这个大目录拖垮了服务，那咱们就给它开个“小灶”：用脚本定时/实时生成这个目录的静态json文件，让nginx访问该目录时直接返回这个预生成的文件，而非实时遍历。

• 实现思路：

  • 写个简单的脚本（比如Python或Shell），扫描目标目录生成符合autoindex格式的json文件；
  • 用inotifywait监听目录的增删改事件，实时更新json；或者用crontab定时执行脚本（比如每5分钟跑一次，根据你的更新频率调整）；
  • 在nginx配置里给这个大目录单独配置，优先返回预生成的json。

• nginx配置示例：

location /your-large-directory/ {
    # 优先返回预生成的json文件
    try_files /path/to/your/pre-generated-dir.json =404;
    # 可选：如果预生成文件不存在， fallback到原生autoindex（不推荐，避免再次阻塞）
    # autoindex on;
    # autoindex_format json;
}

2. 调整nginx参数缓解阻塞影响 #

这个方法不能彻底解决单个请求的阻塞问题，但能让其他请求还有机会被处理，不至于全服务冻结：

• 把worker_processes设置为和CPU核心数一致（或者直接用auto），这样当一个worker被阻塞时，其他worker可以处理其他请求：

worker_processes auto;

• 提高worker_rlimit_nofile的数值，避免遍历大量文件时触发文件描述符上限：

worker_rlimit_nofile 65535;

• 同时调整events块里的worker_connections，保证足够的连接处理能力：

events {
    worker_connections 10240;
}

3. 优化文件系统的目录性能 #

针对btrfs文件系统，你可以尝试优化目录的元数据处理：

• 确认btrfs是否开启了dir_index特性（默认应该是开启的，但可以检查下），这个特性会给目录建立索引，加快文件查找和遍历速度；
• 如果可能的话，把这个大目录拆分成多个子目录（比如按文件名首字母、文件创建日期等分类），减少单个目录的文件数量，从根源上缩短autoindex的遍历时间。

关于是否要提交bug的问题 #

nginx的autoindex模块本身就是设计为同步遍历目录的，目的是保证返回的目录列表是实时的。如果觉得这种超大量文件的场景需要优化（比如加入异步遍历的选项），你可以去nginx官方的issue tracker提交需求，但短期来看官方不会快速修改这个逻辑，所以还是优先用前面的方法解决当前问题更实在。

备注：内容来源于stack exchange，提问作者Hykilpikonna