Nginx非阻塞I/O与Linux页缓存协同提升小文件服务性能：依赖page cache实现零磁盘读取复用，sendfile实现零拷贝直通，open_file_cache减少元数据开销，禁用directio保障缓存有效性。
Nginx 的非阻塞 I/O 不是孤立运行的，它和 Linux 内核的页缓存（page cache）协同工作，形成一套高效、低开销的小文件服务机制。关键不在于“绕开”内核，而是在非阻塞前提下，最大化复用已缓存的数据，避免重复读盘和多余拷贝。
依赖 page cache 做首次读取与后续复用
当 Nginx 处理静态小文件请求（如 JS、CSS、图标）时，它默认走的是标准缓存 I/O 路径：内核先检查 page cache 中是否已有该文件内容；有则直接返回，无则从磁盘加载进 page cache，再提供给 Nginx。这个过程对 Nginx 是透明的，但至关重要——非阻塞 I/O 只负责“什么时候去读”，而 page cache 决定了“读什么、从哪读”。
- 只要文件被访问过一次，后续请求大概率命中 page cache，read() 系统调用几乎瞬间返回，不会触发实际磁盘 I/O
- Nginx worker 进程在 epoll_wait 返回可读事件后，调用 read()，此时若数据已在 page cache，就直接进入用户态缓冲区（或跳过，见 sendfile）
- 无需手动开启或配置 page cache，它是 Linux 文件系统默认行为，Nginx 默认就受益于此
sendfile 零拷贝直通 page cache
这是非阻塞 I/O 与内核缓存协作最典型的体现。启用 sendfile on 后，Nginx 不再调用 read() + write()，而是让内核直接把 page cache 中的数据复制到 socket 发送队列：
- 完全避开用户态内存，省去两次系统调用和两次数据拷贝
- 整个过程仍基于非阻塞语义：如果 socket 发送缓冲区满，内核返回 EAGAIN，Nginx 就把连接挂回 epoll 的可写事件队列，等下次通知再继续
- 要求文件句柄是普通文件（不能是管道或套接字），且未启用 gzip/sub_filter 等需修改响应体的模块
open_file_cache 减少元数据系统调用干扰
非阻塞 I/O 的效率会被频繁的 stat()、open() 拖累——这些调用虽不读文件内容，但每次都要查 inode、权限、是否存在，也走内核路径。open_file_cache 就是为缓解这个问题而设：
- 缓存文件是否存在、是否可读、inode 和 size 等元数据，避免每个请求都触发一次 stat()
- 搭配 open_file_cache_valid 和 open_file_cache_min_uses，确保缓存既不过期也不滥用内存
- 错误结果（如“文件不存在”）也可缓存（open_file_cache_errors on），防止扫描类请求反复穿透到磁盘
避免 directio 破坏 page cache 协同
directio 指令会让读操作绕过 page cache，直接读磁盘（O_DIRECT）。这对大文件流式传输有意义，但对小文件是负优化：
- 每次请求都强制磁盘寻道，失去操作系统级缓存收益
- 与非阻塞 I/O 不冲突，但破坏了“一次加载、多次复用”的核心协作逻辑
- 小文件场景应保持 directio off（默认即如此），专注让数据留在 page cache 中
不复杂但容易忽略：非阻塞只是调度方式，真正提升吞吐的是让内核缓存“一直有用”。配置上做减法（关日志、禁正则匹配）、做缓存（open_file_cache、sendfile）、不做干扰（不用 directio），就能让两者稳稳配合。
