При анализе системных журналов PostgreSQL, обслуживающего базы данных 1С:Предприятие, системные администраторы часто сталкиваются с регулярными предупреждениями вида LOG: checkpoints are occurring too frequently. Разберем детально, почему возникает данная ситуация, как работают контрольные точки в СУБД и как правильно рассчитать параметры журнала транзакций для снижения нагрузки на дисковую подсистему.
Контрольная точка (чекпоинт) — это операция периодической синхронизации данных, при которой все измененные («грязные») страницы из оперативной памяти (буферного кэша shared_buffers) принудительно сбрасываются на постоянный диск, а в журнале предзаписи (WAL) ставится отметка о согласованности состояния.
Срабатывание контрольной точки инициируется по одному из двух условий:
checkpoint_timeout определяет максимальный временной промежуток между автоматическими чекпоинтами.Когда база 1С выполняет интенсивную запись (например, при проведении документов, групповом перепроведении, реструктуризации таблиц или обновлении конфигурации), объем WAL-записей заполняется быстрее, чем наступает checkpoint_timeout. Если контрольная точка происходит чаще, чем задано порогом checkpoint_warning (по умолчанию 30 секунд), PostgreSQL выводит предупреждение о слишком частых чекпоинтах.
Проанализируем скрытую опасность частых контрольных точек. В PostgreSQL действует механизм защиты от повреждения данных при сбоях — full_page_writes. Сразу после завершения каждого чекпоинта первое изменение любой страницы таблицы или индекса приводит к записи всей 8-килобайтной страницы целиком в журнал предзаписи WAL, а не только дельты изменений.
Если контрольные точки происходят слишком часто, объем генерируемого WAL-трафика лавинообразно растет, создавая колоссальную нагрузку на дисковую подсистему и вызывая деградацию общей скорости работы пользователей в 1С.
В устаревших версиях СУБД (например, 9.4 и более ранних) объем журнала между чекпоинтами регулировался параметром checkpoint_segments. По умолчанию значение составляло всего 3 сегмента (по 16 МБ каждый), чего категорически недостаточно для транзакционной нагрузки 1С.
Рассмотрим порядок настройки параметров в конфигурационном файле postgresql.conf:
checkpoint_segments задается в диапазоне от 32 до 256 в зависимости от интенсивности записи и доступного дискового пространства.checkpoint_timeout рекомендуется повышать с типовых 5min до 15min или 30min.checkpoint_completion_target выставляем в значение 0.9, что позволяет растянуть дисковую запись на 90% интервала между точками и избежать резких пиков ввода-вывода (I/O spikes).Начиная с версии PostgreSQL 9.5 механизм управления журналами был модернизирован: параметр checkpoint_segments упразднен, а вместо него введены динамические параметры min_wal_size и max_wal_size.
Разберем базовые оптимальные настройки для конфигурации postgresql.conf:
4GB до 16GB (или более при высоких нагрузках).1GB до 2GB). Система не удаляет файлы журналов ниже этого порога, а переименовывает и переиспользует их, экономя операции создания файлов на диске.15min до 30min. Следует помнить, что увеличение интервала немного увеличивает время автоматического восстановления базы после внезапного аварийного выключения питания, но существенно разгружает диски в штатном режиме.16MB (или -1 для автоматического выделения 1/32 от размера shared_buffers).Иногда при выполнении обновлений или пакетных операций на фоне предупреждений чекпоинтов возникает ошибка Out of memory for query result. Выясним причину ее появления:
rphost.В логах модифицированных сборок PostgreSQL для 1С при системных запросах может фиксироваться запись Can't find mchar/mvarvarchar types: mchar=0 mvarchar=0. Данное сообщение имеет уровень LOG и возникает при подключении системных утилит или фоновых служб к базам данных, где не активированы специализированные расширения типов данных 1С. Если основные информационные базы работают штатно, это сообщение носит исключительно информационный характер и не требует вмешательства.