合理缩小--storage.tsdb.max-block-duration并协同设置min-block-duration与retention可避免compaction io高峰，如retention=15d时设max=16d、min=4h，防止老旧小块堆积和临期突击合并。

调大 --storage.tsdb.max-block-duration 并不能避免大块 Compaction 时的 IO 高峰，反而可能加剧它。真正有效的做法是：**合理缩小该值，并与保留期、最小块时长协同控制压缩节奏**。

为什么 max-block-duration 过大会抬高 Compaction IO

TSDB 的 Compaction 是将多个小块合并为一个更大块的过程。如果 --storage.tsdb.max-block-duration 设得过大（比如 30d），会导致：

• 老旧小块长期滞留，无法及时参与合并，堆积在磁盘上
• 当最终触发 compaction 时，需一次性合并大量分散的小块，跨块读取、重编码、重索引，IO 密集度陡增
• 合并后的大块体积膨胀，写入放大明显，进一步拉高磁盘吞吐压力

推荐设置：略大于 retention，不追求“最大”

该参数本质是“单个块最长存活时间”，不是“越大越好”。生产中应让它紧贴数据生命周期：

• 若 --storage.tsdb.retention.time=15d，建议设 --storage.tsdb.max-block-duration=16d
• 若 retention 是 7d，max-block-duration 可设为 8d 或 9d
• 这样能确保过期前完成合并，避免“临期突击 compact”式的 IO 冲击

必须同步约束 min-block-duration 和 retention 关系

单独调 max 值无效，需三者联动：

• min-block-duration 建议设为 4h 或 6h（避免 15m/30m 等过小值引发高频小块）
• max-block-duration 必须 ≥ min-block-duration，且差值不宜过大（如 min=4h、max=16d 就失衡）
• retention 必须略小于 max-block-duration，否则过期清理和 compaction 逻辑冲突，残留无效块并干扰后续压缩

配合其他措施降低 Compaction 负载

光调参数不够，还需从源头减少待压缩数据量：

• 禁用高基数标签（如 request_id、trace_id），防止 series 数爆炸
• 通过 metric_relabel_configs 提前 drop 无用指标，减少写入样本数
• 检查 --storage.tsdb.head-chunks-write-queue-size 是否过小，避免 WAL 积压倒逼频繁 flush 和后续密集 compaction