日志滚动越频繁、单文件越小，通常反映并发写入压力越高；例如配置10MB阈值却每2分钟滚动一次，表明写入速率约85KB/s，持续超50KB/s需警惕I/O压力。
通过日志文件的滚动周期评估并发写入压力，核心是观察单位时间内日志文件的生成频率与体积变化——滚动越频繁、单个文件越小，往往意味着日志写入速率越高，背后可能反映较高的并发请求量或密集的日志输出行为。
看滚动触发条件是否由大小驱动
若使用 Logback 或 Log4j2 的基于文件大小的滚动策略（如 SizeAndTimeBasedRollingPolicy），重点关注 fileSize 阈值和实际滚动间隔：
- 配置中设定了
maxFileSize="10MB"，但日志文件平均 2 分钟就滚一次 → 实际写入速率约 5MB/min，换算约 85KB/s；持续高于 50KB/s 就需警惕 I/O 压力 - 同一服务在低峰期滚动周期为 30 分钟，高峰期缩至 90 秒 → 滚动频次提升 20 倍，可初步判断写入压力剧增，需结合 QPS 数据交叉验证
- 注意排除“突发性大日志”干扰：单次滚动快不等于持续高压，要统计连续 5~10 个滚动周期的平均时长和文件大小方差
比对时间窗口内的滚动次数与业务指标
将日志滚动行为与监控系统中的关键指标对齐，建立关联性判断：
- 每小时滚动 120 个文件（按 5 分钟一滚），同时 Prometheus 显示该时段平均 HTTP QPS 为 1800 → 粗略估算单请求平均产生约 67KB 日志（含堆栈、参数、耗时等），明显偏高，应检查是否误开 DEBUG 级别或重复打印
- 滚动周期稳定在 1 小时（按时间滚动），但某天凌晨 2:00–3:00 突然出现 8 次滚动 → 结合告警发现该时段有定时批处理任务启动，确认是阶段性写入高峰，非系统异常
- 对比不同模块日志：订单服务每 3 分钟滚一次，用户服务每 40 分钟滚一次 → 在相同日志级别下，说明订单侧日志密度显著更高，可定向优化其日志粒度
检查滚动后文件的压缩与归档延迟
滚动本身不耗时，但后续压缩（如 .gz）、移动到归档目录、清理旧文件等操作会暴露 I/O 瓶颈：
立即学习“Java免费学习笔记（深入）”；
- 滚动后 3 秒内完成重命名，但压缩常卡在 8~15 秒 → 说明磁盘吞吐或 CPU 压缩能力成为瓶颈，此时即使应用线程未阻塞，也已影响日志可靠性
- 归档目录所在磁盘 iowait > 20%，且滚动期间应用 GC 时间同步上升 → 可能因日志刷盘抢占 I/O 导致 JVM 内存回收变慢，形成连锁压力
- 建议在测试环境模拟高写入场景：用
dd if=/dev/urandom of=/var/log/app/app.log bs=1M count=500占用磁盘带宽，观察真实滚动行为是否延迟或失败
结合日志内容采样反推写入源头
滚动周期只是表象，需打开最新滚动文件抽样分析，定位压力来源：
- 用
zcat app.log.2024-05-20.1.gz | head -n 1000 | awk '{print $4}' | sort | uniq -c | sort -nr | head -5查看高频类名 → 若 70% 行来自OrderService.logPayment，说明支付链路日志最密集 - 搜索
DEBUG行占比：全量日志中 DEBUG 占比超 40%，而生产环境通常应 - 检查是否有重复日志：同一请求 ID 在 100ms 内出现 5 次“start processing”，大概率是 AOP 切面 + 手动 log 混用，造成无效写入倍增
