压测日志吞吐需分层验证：一看请求延迟增幅是否超5%，二看iostat中%util/await是否持续超80%，三看关闭缓冲后error.log是否报write/open失败；自定义格式应精简高开销字段如$host、$cookie_xxx；推荐配置buffer=128k flush=1s，挂载nvme ssd并设noatime,nobarrier，调大文件句柄上限。
直接压测日志吞吐表现，不能只看“能不能写”，而要看“在高并发下是否拖慢主流程、是否丢日志、是否引发磁盘或IO瓶颈”。Nginx 自定义日志格式本身不直接影响性能，但它的字段数量、变量计算开销、输出目标（磁盘 vs 缓存）、以及是否启用异步刷盘，会显著影响压测时的真实吞吐能力。
一、关键测试维度要覆盖这三项
压测日志吞吐，不是跑个 ab 或 wrk 就行，必须分层验证：
- 请求处理延迟变化：开启自定义日志前后，在相同 QPS 下对比 upstream_response_time 和 request_time 的 P95/P99 增幅。若增幅超过 5%，说明日志写入已开始反向拖累业务链路；
-
日志落盘稳定性：用
tail -f access.log | pv -l实时统计每秒行数，同时观察iostat -x 1中 %util 和 await 是否持续超 80% 或飙升； -
缓冲区与丢日志风险：强制关闭日志缓冲（
log_format后不加buffer=64k flush=5s），在万级并发下观察 error.log 是否出现write() failed (9: Bad file descriptor)或open() failed (24: Too many open files)—— 这说明文件描述符或内核 write buffer 已耗尽。
二、自定义格式的性能敏感点要精简
以下字段在压测中开销差异明显，需按需取舍：
- 低开销（推荐保留）：$remote_addr、$time_local、$request、$status、$body_bytes_sent、$request_time；
- 中开销（慎用，尤其高并发）：$http_x_forwarded_for（需字符串解析）、$upstream_response_time（依赖 upstream 状态）、$request_length（需计算长度）；
- 高开销（压测期间建议关闭）：$host（DNS 反查触发）、$cookie_xxx（正则匹配）、$sent_http_xxx（响应头读取，可能触发 header 解析延迟）、嵌套 map 变量（如基于 $uri 做条件判断）。
三、真实压测配置建议（OpenEuler / CentOS 8+ 环境）
为逼近极限，需协同调优系统与 Nginx 层：
- 启用高效写入：
access_log /var/log/nginx/access.log main buffer=128k flush=1s;（缓冲区设大，减少 syscalls）； - 绑定独立磁盘：将日志目录挂载到 NVMe SSD，并设置
noatime,nobarrier挂载选项； - 提升文件句柄上限：确保
fs.file-max=2097152和worker_rlimit_nofile 1048576已生效（参考 OpenEuler 全链路优化实践）； - 禁用日志轮转干扰：压测期间临时注释
logrotate配置，避免kill -USR1触发重开文件句柄造成抖动。
四、快速验证是否达到日志瓶颈
不用等压测结束，边跑边查这几项：
- 执行
ss -s：看total:连接数是否远高于used:，若差值持续 >5000，说明连接未及时释放，可能被日志 IO 卡住； - 运行
cat /proc/$(pgrep nginx)/stack | grep do_syscall_64：若大量线程卡在sys_write或ext4_file_write_iter，即为日志写入阻塞； - 对比
nginx -t && systemctl reload nginx后首分钟 QPS 波动：若 reload 后 QPS 突降 10% 以上，大概率是新日志格式触发了变量缓存失效或初始化开销。
