Почему PostgreSQL работает медленнее MS SQL в 1С и как это исправить?

Системный администратор 1С v8.3 (Управляемые формы) 1С:Зарплата и Управление Персоналом IT и автоматизация бизнеса
← На главную

Многие технические специалисты при переходе с MS SQL Server на PostgreSQL сталкиваются с неприятным сюрпризом: производительность системы на свободной СУБД оказывается значительно ниже, иногда в десятки раз. Особенно это заметно при массовой записи документов в конфигурациях типа "Зарплата и управление персоналом" (ЗУП). Разберем по шагам, почему так происходит, как диагностировать узкие места и что нужно сделать, чтобы PostgreSQL работал быстрее, чем коммерческие аналоги.

Анализируем ситуацию: почему запись документов тормозит

Рассмотрим типичный сценарий: при записи документа БольничныйЛист со включенным флагом ОбменДанными.Загрузка = Истина скорость в MS SQL составляет около 26 документов в секунду, а в PostgreSQL — всего 1.5 документа. На первый взгляд кажется, что проблема в самой СУБД, однако в 99% случаев причина кроется в отсутствии оптимизированных индексов или некорректных планах запросов.

Выясним причину такого поведения. Для этого нам необходимо заглянуть "под капот" СУБД и увидеть, какие именно запросы выполняются в момент записи документа. В 1С метод Записать() инициирует не только вставку данных, но и предварительное чтение объекта, проверку табличных частей и системных полей.

Шаг 1. Настройка логирования планов запросов (auto_explain)

Чтобы понять, где именно PostgreSQL "спотыкается", воспользуемся модулем auto_explain. Он позволяет выводить планы выполнения медленных запросов прямо в лог-файл СУБД. Проанализируем настройки, которые необходимо внести в файл postgresql.conf:


shared_preload_libraries = 'auto_explain'
auto_explain.log_min_duration = '0'
auto_explain.log_analyze = true
auto_explain.log_buffers = true
auto_explain.log_timing = true

Важный нюанс: Установка параметра auto_explain.log_min_duration = '0' заставит систему логировать абсолютно все запросы. Это создаст большую нагрузку, поэтому используйте эту настройку только на время теста. После настройки мы увидим, что при выполнении метода ПолучитьОбъект платформа 1С формирует десятки запросов к основной таблице документа и ко всем его табличным частям.

Шаг 2. Интерпретация плана запроса: Seq Scan против Index Scan

Проанализируем фрагмент лога, полученного после записи документа. В проблемных случаях мы увидим примерно следующую картину:


Query Text: SELECT T2._LineNo1046, T2._Fld1047RRef ... FROM _Document304_VT1045 T2 ...
...
-> Seq Scan on _document304_vt1045 t2 (cost=0.00..2837.60 rows=2 width=420)
Filter: ((_fld815 = '0'::numeric) AND (_document304_idrref = '\\x8721...'::bytea))
Rows Removed by Filter: 37882
Buffers: shared read=2383

Посмотрим внимательнее на строку Seq Scan. Это означает Sequential Scan — последовательное сканирование всей таблицы. PostgreSQL физически читает все 37 882 строки из таблицы табличной части документа, чтобы найти всего одну нужную запись. Это происходит потому, что у СУБД нет подходящего индекса по полям разделителя (_fld815) и ссылки (_document304_idrref).

В MS SQL такие индексы часто создаются автоматически или поддерживаются более агрессивно, а в PostgreSQL при определенных манипуляциях с базой (например, некорректном переносе данных) они могут отсутствовать или быть повреждены.

Шаг 3. Решение проблемы через реструктуризацию 1С

Самый простой и эффективный способ восстановить индексы в соответствии с логикой платформы 1С — это процедура реструктуризации. Не стоит пытаться создавать индексы вручную через SQL-запросы, так как платформа 1С должна "знать" об их существовании.

Выполним следующие действия:

  1. Запустим информационную базу в режиме Конфигуратор.
  2. Перейдем в меню Администрирование — Тестирование и исправление...
  3. Установим флаг только на пункте Реструктуризация таблиц информационной базы.
  4. Выберем вариант "Создавать новые объекты" (хотя в данном случае это не критично).
  5. Нажмем кнопку "Выполнить" и дождемся завершения процесса.

После этой операции PostgreSQL создаст все необходимые индексы, включая те, что имитируют кластерные индексы MS SQL. Как показывает практика, после реструктуризации скорость записи может вырасти с 1.5 до 40 документов в секунду, что даже превосходит показатели MS SQL в некоторых тестах.

Шаг 4. Дополнительный "разгон" и тонкая настройка

Если реструктуризация помогла, но вы хотите выжать из системы максимум, проанализируем дополнительные параметры оптимизации PostgreSQL для Linux-систем (Ubuntu, Astra Linux):

  1. Отключение Synchronous Commit: По умолчанию PostgreSQL ждет, пока данные физически запишутся на диск. Для 1С это часто избыточно. Установите synchronous_commit = off в конфиге. Это даст колоссальный прирост на операциях записи.
  2. Параметр Random Page Cost: Для современных SSD/NVMe дисков значение по умолчанию (4.0) слишком велико. Установите random_page_cost = 1.1. Это заставит планировщик чаще использовать индексы (Index Scan), а не переходить на Seq Scan.
  3. Настройка Autovacuum: В 1С таблицы постоянно меняются. Чтобы "мертвые" строки не замедляли работу, настройте более частую очистку: 
    
autovacuum_vacuum_scale_factor = 0.01
autovacuum_analyze_scale_factor = 0.005
  4. Transparent Huge Pages (THP): На уровне операционной системы Linux обязательно отключите THP. Эта функция часто вызывает задержки (stalls) при выделении памяти для процессов СУБД.

Итоги и рекомендации по обслуживанию

Рассмотрим, нужно ли делать реструктуризацию постоянно. Нет, это разовая акция для исправления структуры. Однако для поддержания высокой скорости работы необходимо регулярно выполнять регламентные операции средствами самой СУБД:

Таким образом, мы выяснили, что PostgreSQL не является "медленным" по своей природе. Его низкая скорость в связке с 1С чаще всего является следствием "потерянных" индексов или неоптимальных настроек планировщика запросов. Использование auto_explain и своевременная реструктуризация позволяют добиться производительности, сопоставимой с MS SQL Enterprise версий.

← На главную