核心是验证高并发下日志切割的可靠性：边压测边切割，确保不丢日志、不阻塞请求、新旧日志边界清晰；需实时监控行数、时间戳连续性及双写现象，并通过多轮交叉压测与定时切割检验稳定性。
测试高并发写入下的日志切割稳定性，核心是模拟真实压测场景 + 验证切割动作不丢日志、不阻塞请求、新旧日志边界清晰。关键不在“能不能切”，而在“边切边扛压时是否可靠”。
准备可复现的压测环境
确保 Nginx 正在持续接收请求，且 access.log 有实时写入：
- 用 ab 或 wrk 发起并发请求，例如：
ab -c 200 -n 50000 http://127.0.0.1/（200 并发，5 万总请求数） - 或用循环 curl 持续刷日志：
while true; do curl -s http://127.0.0.1/ > /dev/null; sleep 0.01; done & - 同时用
tail -f /var/log/nginx/access.log | wc -l观察日志行数是否稳定增长
在压测中触发日志切割
不要等压测结束再切——要选在流量高峰中执行切割操作，才能暴露竞争问题：
- 手动运行切割脚本（如
./cut_log.sh），或直接执行等效命令：mv /var/log/nginx/access.log /var/log/nginx/access_$(date +%F_%H%M).log && kill -USR1 $(cat /var/run/nginx.pid) - 注意：mv 和 kill -USR1 必须紧邻执行，中间不能有明显延迟，否则可能漏写几行到旧文件
- 推荐在另一终端用
ls -lt /var/log/nginx/access*实时观察文件时间戳和大小变化
验证切割是否真正稳定
检查三件事：有没有丢日志？有没有写错位置？新日志是否立刻生效？
-
比对请求数与日志行数：压测前记下
wc -l access.log，压测中切一次，切完立即查新旧两个文件总行数，应 ≈ 总请求数 ±1～2 行（网络波动或 4xx/5xx 可能不记日志） -
检查时间戳连续性：用
tail -n 5看旧日志末尾时间和新日志开头时间，应无缝衔接（最多差 1 秒）；若出现跳秒或重复，说明 USR1 信号未及时生效或工作进程未同步 - 确认无双写现象：切割后继续压测 30 秒，检查是否仍有新条目写入旧文件名（已 mv 的那个）。若有，说明 nginx 工作进程仍持有旧文件描述符未释放——常见于未正确发送 USR1 或 pid 文件路径错误
加压 + 多次切割交叉验证
单次成功不代表稳定，需模拟运维真实节奏：
- 设置定时任务每 5 分钟切一次，同时保持 ab -c 300 压测 30 分钟
- 观察
ps aux | grep nginx中 worker 进程是否始终存活，有无因信号处理异常导致重启 - 检查系统负载（
uptime、iostat -x 1），确认切割脚本本身没引发 I/O 阻塞或 CPU 尖峰
