NGINX的access_log走用户态缓冲+内核Page Cache路径，不绕过也不强制sync；日志先写入worker内存buffer（如buffer=128k），满或超时（如flush=1s）后调用writev进入Page Cache，再由内核异步刷盘。
NGINX 的 access_log 不经过内核态缓存，它走的是用户态文件 I/O 路径，由 worker 进程直接调用 libc 的 fwrite 或 writev 写入，底层依赖系统调用（如 write()），但不主动绕过 page cache，也不强制 sync —— 它默认信任内核的页缓存机制来提升吞吐。
access_log 的实际写入流程
每条访问日志的生成和落盘，经历以下关键阶段：
-
请求生命周期末尾触发：在 HTTP 请求处理的
log阶段（即所有 upstream 响应已返回、header 已发送、body 可能未完全发出时），NGINX 才开始格式化并准备写 access log；此时$request_time、$upstream_response_time等变量才具备最终值。 -
格式化与内存缓冲：根据
log_format拼接字符串，结果暂存于 worker 进程的内存 buffer 中（默认 64KB）；buffer 满、或达到flush时间阈值（如flush=5s）、或 worker 重启/重载时，才会批量刷出。 -
写入系统调用层：调用
writev()（支持向量写）一次性提交多条日志行，避免频繁 syscall 开销；该调用进入内核后，数据先写入 VFS 层的 page cache，而非直接落盘。 -
内核 page cache 管理：Linux 内核自动管理该缓存，脏页由
pdflush或writeback机制异步刷回磁盘；除非配置了O_SYNC（NGINX 不启用），否则不等待物理写入完成。
为什么 NGINX 不绕过 page cache
绕过 page cache（如用 O_DIRECT）会带来显著性能代价：
- 要求内存对齐（通常 512B 或 4KB），NGINX 日志 buffer 是动态拼接的字符串，难以满足；
- 失去内核合并 IO、预读、延迟写等优化能力，小日志写入会变成大量随机短 IO；
- 增加 worker 进程的 CPU 和上下文切换开销，反而降低高并发下的吞吐能力。
因此，NGINX 默认行为是“信任 page cache”，并通过 buffer 和 flush 参数在内存中做二次聚合，以减少 write 系统调用频次，让内核更高效地调度真实磁盘 IO。
Teleport tsh SSH (Identity-First SSH Access, no passwords/static keys)
下载
使用tbot机器ID身份文件配合tsh CLI，通过Teleport访问控制SSH登录托管主机或执行远程命令。
影响落盘及时性的关键配置
真正决定日志“何时可见于磁盘文件”的，不是 NGINX 自身，而是如下三者协同作用：
-
access_log ... buffer=SIZE flush=TIME：控制用户态 buffer 大小与超时，决定日志在内存中停留多久； -
内核
vm.dirty_ratio/vm.dirty_background_ratio：影响 page cache 脏页何时被内核后台线程刷出； -
存储设备特性：如使用带电容保护的 NVMe SSD，page cache 刷盘延迟通常在毫秒级；若挂载为
noatime,nobarrier,commit=60的 ext4，则可能延长至数十秒。
如何验证日志是否已落盘
不能仅靠 tail -f access.log 是否显示新行来判断物理落盘 —— 它只反映 page cache 内容。可靠方式包括：
- 执行
sync; echo 3 > /proc/sys/vm/drop_caches后再检查文件 mtime 和 size； - 用
strace -e trace=write,writev -p $(pgrep nginx)观察是否发生系统调用（注意仅限调试，勿在线上长期运行）； - 在日志路径所在文件系统上启用
auditd或bpftrace监控sys_write返回值，确认 write 成功且无 EAGAIN/EWOULDBLOCK。
不复杂但容易忽略：access_log 的“实时性”本质是用户态缓冲 + 内核页缓存的两级延迟叠加，理解这点，才能合理设置 buffer/flush 并正确解读监控与故障排查中的时间差。
