При переходе с MS SQL Server на PostgreSQL многие системные администраторы и разработчики сталкиваются с резким падением производительности в типовых конфигурациях, таких как 1С:Комплексная автоматизация 2 (КА2) или 1С:ERP. Типичная ситуация: проведение одного регламентного документа (например, "Расчет себестоимости" или "Отражение документов в регл. учете") занимает от 3 до 8 минут, в то время как на MS SQL та же операция выполняется за секунды. Проанализируем причины этой проблемы и разберем по шагам методы оптимизации, которые позволяют сократить время выполнения операций в 10 раз и более.
Первым делом проанализируем состояние системы во время "зависания". Если мы заглянем в системный мониторинг PostgreSQL (например, используя утилиту pg_top или анализируя pg_stat_activity), мы увидим, что основное время тратится на операции UPDATE в таблицах итогов регистров бухгалтерии. В 1С:КА 2 эти таблицы имеют префикс _AccRgAT. Рассмотрим пример типичного запроса, вызывающего задержку:
UPDATE _AccRgAT261025
SET _Fld60987 = COALESCE(CAST(_AccRgAT261025._Fld60987 AS NUMERIC(21, 2)), 0) + -275.45,
_Fld60990 = COALESCE(CAST(_AccRgAT261025._Fld60990 AS NUMERIC(21, 2)), 0) + -275.45
WHERE _AccRgAT261025._Period = '2019-05-01 00:00:00'
AND _AccRgAT261025._AccountRRef = '\\264\\362\\330P...'
Выясним причину, по которой простой UPDATE может выполняться по 5-6 секунд. Основная проблема заключается в том, что планировщик PostgreSQL может строить неэффективный план запроса из-за неактуальной статистики или специфических настроек расширений. Рассмотрим комплекс мер по решению этой задачи.
Одной из главных причин "диких тормозов" в связке 1С и PostgreSQL является работа модуля online_analyze. Этот модуль предназначен для немедленного обновления статистики после изменения данных. Рассмотрим, как его неправильная настройка влияет на производительность. Если параметр online_analyze.table_type установлен в значение all, система пытается пересчитать статистику для всех таблиц, включая тяжелые таблицы итогов, при каждом изменении. Это создает огромную нагрузку на UPDATE.
Разберем оптимальную конфигурацию этого модуля в файле postgresql.conf:
online_analyze.enable = on.online_analyze.table_type = 'temporary'. Это заставит модуль анализировать только временные таблицы, которые 1С создает в огромных количествах во время проведения документов. Для постоянных таблиц вполне достаточно работы стандартного autovacuum.
online_analyze.threshold = 50
online_analyze.scale_factor = 0.1
online_analyze.local_tracking = on
online_analyze.min_interval = 10000
Практика показывает, что переключение online_analyze.table_type с all на temporary само по себе может ускорить проведение документов в несколько раз, так как СУБД перестает выполнять избыточную работу по анализу постоянных таблиц при каждом движении документа.
Посмотрим на ситуацию со стороны 1С. В конфигурациях на базе ERP и КА 2 таблицы итогов часто "раздуваются" из-за наличия записей с нулевыми значениями или некорректно рассчитанных периодов. Проанализируем состав таблицы итогов через консоль запросов или напрямую в базе:
SELECT count(_period) FROM _accrgat261025 WHERE _period = '3999-11-01 00:00:00';
Если в таблице скопилось огромное количество записей (сотни тысяч), это замедляет любой поиск и обновление. Выполним следующие действия в 1С:
В ходе этой операции 1С удалит пустые и неактуальные записи. Разберем пример: до пересчета в таблице могло быть 230 000 строк, после — 65 000. Уменьшение объема данных напрямую снижает время выполнения UPDATE.
Проанализируем файл postgresql.conf и внесем правки, специфичные для работы с 1С. Рассмотрим основные параметры, которые должны быть настроены:
Параметры памяти:
shared_buffers: установим значение в размере 1/4 от всей оперативной памяти сервера (например, 8GB для 32GB RAM).work_mem: для 1С рекомендуется увеличивать это значение (от 64MB до 256MB), чтобы сложные JOIN выполнялись в памяти, а не на диске.maintenance_work_mem: увеличим до 1GB или 2GB для ускорения операций VACUUM и REINDEX.Параметры планировщика (Optimizer): Для предотвращения выбора неверных планов при сложных запросах 1С, рассмотрим следующие настройки:
seq_page_cost = 0.1
random_page_cost = 0.4 # Значение для SSD, для HDD используйте 1.5-2.0
cpu_operator_cost = 0.00025
effective_cache_size = # Установите в размере оставшейся свободной RAM (RAM - shared_buffers)
Отключение JIT (для PostgreSQL 11 и выше):
В версиях 11+ часто наблюдается проблема, когда JIT-компиляция тратит больше времени на анализ запроса, чем длится сам запрос. Отключим его:
jit = off.
Выясним причину возможных "микрофризов", связанных с ядром Linux. Одной из неочевидных проблем является механизм Transparent Huge Pages (THP). Для баз данных его рекомендуется отключать, так как он может вызвать задержки при выделении памяти процессом PostgreSQL.
Проанализируем текущее состояние и отключим THP:
cat /sys/kernel/mm/transparent_hugepage/enabled.always, добавим transparent_hugepage=never в параметры загрузки ядра в /etc/default/grub и выполним update-grub.Также рассмотрим настройку synchronous_commit. Если надежность питания сервера обеспечена ИБП, установка synchronous_commit = off даст колоссальный прирост скорости на операциях записи (UPDATE/INSERT), так как СУБД не будет ждать физического подтверждения записи на диск при каждой транзакции.
Рассмотрим результаты после выполнения всех шагов. В типичном случае время проведения документа снижается с 400 секунд до 1-1.5 секунд. Мы добились этого за счет:
online_analyze только временными таблицами.Помните, что PostgreSQL требует регулярного обслуживания. Настройте ежедневное выполнение ANALYZE и еженедельное VACUUM FREEZE для поддержания актуальности статистики и чистоты базы данных.