🛠️ 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.

🔹🔹🔹🔹