Nginx access_log的buffer参数通过内存缓冲实现批量落盘，减少I/O次数和worker阻塞；需配合flush使用，推荐buffer=32k～64k、flush=1s，兼顾性能与数据安全。
Nginx 的 access_log 的 buffer 参数，本质是把日志从“每条请求都同步写磁盘”变成“先攒内存、再批量落盘”，直接减少系统调用和磁盘 I/O 次数，从而显著缓解 worker 进程被阻塞的风险。
buffer 是 per-worker、per-log 的内存暂存区
每个 worker 进程为每条 access_log 指令单独分配一块固定大小的缓冲区（比如 buffer=64k 就是 64KB）。日志行不立刻落盘，而是追加进这块内存；只有满足以下任一条件才真正触发 write()：
- 缓冲区被填满
- 到达
flush设定的时间上限（必须配合使用） - worker 进程退出或 reload 配置
这意味着：原本 QPS 5000 时每秒 5000 次小写，可能变成每秒 1–3 次 32–64KB 的大写，IOPS 和平均等待时间（await）明显下降。
合理取值才能兼顾效果与安全
-
buffer=32k～64k是多数中高并发场景的稳妥选择：单次可聚合数百条日志，内存开销低（如 4 个 worker 仅占 256KB），宕机最多丢失约 1 秒数据 - 小于
16k聚合效果弱，几乎等同于未启用；大于128k会拉长日志可见延迟，且异常退出时丢失量陡增 - 日志格式越长（如含
$request_body或长$http_user_agent），buffer 填满越快，实际刷盘频率反而更高
单设 buffer 没用，必须配 flush
只写 buffer=64k 不设 flush，Nginx 会在 buffer 满、reload 或进程退出时才写盘。低流量时段可能卡住几秒甚至几十秒，既影响实时排查，又放大丢志风险。真正起效的写法是：
access_log /var/log/nginx/access.log main buffer=64k flush=1s;
效果不是靠“更快写”，而是“更少写”
它不加速磁盘本身，而是让 worker 大部分时间只操作内存——零系统调用、零磁盘等待。真正的 write() 和 fsync() 变成可预测的低频动作，事件循环不再被日志拖慢。配合 SSD、noatime 挂载和 open_log_file_cache，整体吞吐提升更明显。
