Оптимизация Checkpoint и дискового ввода-вывода в PostgreSQL: max_wal_size
- Периодические зависания (фризы) проведения документов в 1С каждые несколько минут.
- В журнале сервера появляются сообщения:
LOG: checkpoints are occurring too frequently (X seconds apart). - Резкие спайки утилизации диска (%util = 100% в iostat) во время сброса грязных буферов на накопитель.
1. Анализ частоты и причин контрольных точек через представление
SELECT
checkpoints_timed AS CheckpointsScheduled,
checkpoints_req AS CheckpointsRequestedDueToWal,
checkpoint_write_time AS WriteTime_ms,
checkpoint_sync_time AS SyncTime_ms,
buffers_checkpoint AS BuffersWrittenByCheckpoint,
buffers_backend AS BuffersWrittenDirectlyByBackends
FROM pg_stat_bgwriter;Если параметр checkpoints_req сопоставим или превышает checkpoints_timed, сервер слишком часто сбрасывает контрольные точки из-за нехватки объема max_wal_size.
2. Тюнинг параметров контрольных точек в postgresql.conf
# --- Сглаживание пиков ввода-вывода ---
checkpoint_timeout = 30min # Редкие контрольные точки (дефолт 5 мин слишком мал)
checkpoint_completion_target = 0.9 # Размазывание записи на 90% времени интервала (27 минут)
# --- Буфер генерации WAL между чекпоинтами ---
max_wal_size = 32GB # Максимальный объем WAL между чекпоинтами
min_wal_size = 4GB # Минимальный резерв для переиспользования файлов
# --- Фоновый писатель буферов (Background Writer) ---
bgwriter_delay = 20ms
bgwriter_lru_maxpages = 400
bgwriter_lru_multiplier = 3.03. Применение и мониторинг в iostat
SELECT pg_reload_conf();# Мониторинг задержек записи в реальном времени
iostat -xz 1 10 Частые вопросы (FAQ)
Что делает параметр checkpoint_completion_target = 0.9?
Он указывает СУБД растянуть процесс записи грязных страниц на 90% времени отпущенного интервала checkpoint_timeout (например, размазать запись равномерно на 27 минут вместо резкого сброса всего объема за 30 секунд).
Как увеличение checkpoint_timeout влияет на время аварийного восстановления после сбоя питания?
Чем реже происходят контрольные точки, тем больше изменений из WAL придется прочитать и применить ядру PostgreSQL при аварийном старте инстанса (фаза REDO будет длиться дольше).
Почему параметр buffers_backend в pg_stat_bgwriter должен стремиться к нулю?
Если клиентским процессам (backend) не хватает чистых страниц в shared_buffers, они вынуждены сами сбрасывать грязные страницы на диск, что вызывает задержки пользовательских транзакций в 1С.
Как принудительно запустить контрольную точку через SQL?
Выполните команду CHECKPOINT; под учетной записью суперпользователя.