🛠️ Storage latency растёт рывками? Проверьте checkpoints PostgreSQL

Для PostgreSQL 18:

SELECT
num_timed,
num_requested,
num_done,
write_time,
sync_time,
buffers_written,
stats_reset
FROM pg_stat_checkpointer;

Важный нюанс PG18:

num_timed и num_requested могут учитывать как выполненные, так и пропущенные checkpoints.

Поэтому смотрите и num_done — число реально выполненных.

И обязательно учитывайте stats_reset.

Дальше:

SHOW checkpoint_timeout;
SHOW max_wal_size;
SHOW checkpoint_completion_target;

checkpoint_timeout не означает «checkpoint строго раз в N минут».

При интенсивной генерации WAL checkpoint может потребоваться раньше, а max_wal_size — soft limit.

Проверьте и WAL:

SELECT wal_bytes, stats_reset
FROM pg_stat_wal;

Если WAL generation вырос, checkpoint profile тоже может измениться.

checkpoint_completion_target распределяет checkpoint I/O по времени.

Уменьшать его ради «быстрого checkpoint» обычно плохая идея: I/O становится более концентрированным.

Также смотрите:

— buffers_written;
— write_time;
— sync_time;
— checkpoint_warning;
— batch/write-heavy workload.

И не используйте CHECKPOINT как регулярное production-лечение.

Диагностика:

I/O spikes
→ checkpointer stats
→ timed/requested/done
→ WAL generation
→ settings
→ logs
→ workload

Сохраните набор метрик, который стоит проверить до изменения настроек checkpoint и WAL.

🔹🔹🔹🔹