Почему тормозит проведение документов в 1С на PostgreSQL в среде Hyper-V и как это исправить

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

Работа связки 1С:Предприятие и PostgreSQL в виртуальной среде — это стандарт индустрии, но иногда возникают ситуации, когда производительность падает до критических отметок. Типичная проблема: документы, которые в файловом режиме проводятся мгновенно, на серверной базе «повисают» на 5–15 минут. При этом ни процессор, ни дисковая подсистема не показывают нагрузки. Разберем по шагам, как диагностировать и решить эту проблему, основываясь на практическом опыте.

Шаг 1. Анализ производительности внутри 1С

Прежде чем менять настройки СУБД, нам необходимо локализовать место возникновения задержки. Рассмотрим ситуацию, когда визуально нагрузка на сервер 1С и сервер PostgreSQL отсутствует. Проанализируем замер производительности в конфигураторе 1С. В рассматриваемом нами случае выяснилось, что 98% времени тратится на одну-единственную операцию — МенеджерЗаписи.Прочитать.

Это говорит о том, что платформа 1С ожидает ответа от СУБД на запрос к конкретному регистру сведений. Если запрос в консоли PostgreSQL выполняется быстро, а при проведении документа «висит», это верный признак того, что проблема кроется в сетевом взаимодействии или специфике работы планировщика запросов внутри транзакции.

Шаг 2. Мониторинг активных запросов в PostgreSQL

Выясним, что именно делает PostgreSQL в момент «зависания». Для этого воспользуемся системным представлением pg_stat_activity. Выполним следующий запрос в консоли запросов (например, через pgAdmin):


SELECT pid, age(clock_timestamp(), query_start), usename, query, state 
FROM pg_stat_activity 
WHERE state != 'idle' AND query NOT ILIKE '%pg_stat_activity%' 
ORDER BY query_start DESC;

Если мы видим запрос, у которого age (время выполнения) постоянно растет, а pid не меняется, значит, СУБД действительно занята обработкой данных или ждет освобождения ресурсов. Обратим внимание на таблицу, к которой идет обращение. В 1С это часто регистры сведений, например, _InfoRg18250.

Шаг 3. Диагностика индексов и статистики

Проанализируем состояние индексов таблицы, на которой происходит затык. Даже если индексы существуют, они могут быть неэффективны или не использоваться из-за некорректной статистики. Проверим коэффициент использования индексов:


SELECT relname, 100 * idx_scan / (seq_scan + idx_scan) percent_of_times_index_used, n_live_tup rows_in_table 
FROM pg_stat_user_tables 
WHERE seq_scan + idx_scan > 0 
ORDER BY n_live_tup DESC;

Если процент использования индекса (percent_of_times_index_used) низкий, а количество строк в таблице большое, PostgreSQL может выбирать Sequential Scan (полное сканирование таблицы). Это происходит из-за фрагментации индексов или устаревшей статистики. Попробуем выполнить полное обслуживание базы:

  1. Запустим vacuumdb.exe -a -z -F -v для очистки мусора и обновления статистики.
  2. Выполним reindexdb.exe для пересоздания индексов.
  3. В самой 1С запустим «Тестирование и исправление» с опцией «Реструктуризация таблиц».

Шаг 4. Настройка PostgreSQL для работы с 1С

Для корректной работы 1С на PostgreSQL (особенно в среде Windows) необходимо внести изменения в postgresql.conf. Рассмотрим ключевые параметры:

Шаг 5. Особенности виртуализации Hyper-V

Если настройки СУБД и индексы в порядке, но тормоза остаются, проанализируем инфраструктуру. В среде Hyper-V часто возникают сетевые задержки из-за технологии VMQ (Virtual Machine Queuing).

Рассмотрим ситуацию: при переносе виртуальной машины на другой физический хост или при переустановке роли Hyper-V проблема исчезает. Это указывает на «затык» в виртуальном коммутаторе или драйверах сетевой карты хоста. Рекомендуется:

  1. Отключить VMQ в настройках сетевых адаптеров на физическом хосте и внутри ВМ.
  2. Проверить параметр NUMA Spanning в настройках Hyper-V. Для высоконагруженных СУБД лучше, чтобы ВМ помещалась в рамки одного физического узла NUMA (одного процессора/чиплета).
  3. Убедиться, что виртуальные диски имеют тип Fixed Size, так как динамические диски могут вызывать задержки при расширении файлов таблиц СУБД.

Шаг 6. Настройка Технологического журнала

Чтобы окончательно убедиться, что проблема в SQL-запросах, настроим Технологический журнал 1С. Создадим файл logcfg.xml в папке conf сервера 1С:


<config xmlns="http://v8.1c.ru/7.4/get/logcfg">
  <log location="C:\LOGS\DBMSSQL" history="24">
    <event>
      <eq property="Name" value="DBPOSTGRS"/>
      <gt property="Duration" value="1000000"/>
    </event>
    <property name="all"/>
  </log>
</config>

Этот лог покажет все запросы к PostgreSQL, которые выполняются дольше 1 секунды. Если мы видим гигантское количество однотипных запросов к bytea полям или некорректное приведение типов (например, CAST(0 AS NUMERIC) вместо прямого сравнения с 0), нам придется оптимизировать код 1С или структуру метаданных через расширения.

Вывод

Проанализировав ситуацию, мы выяснили, что тормоза при проведении документов часто являются комплексной проблемой. Если 1С «зависает» на методе МенеджерЗаписи.Прочитать, а нагрузка на сервер минимальна — ищите проблему в настройках Hyper-V (сетевой стек) или в параметрах планировщика PostgreSQL (JIT, Plan Cache). Перенос базы на другой хост или переустановка роли виртуализации часто является самым быстрым способом устранить скрытые дефекты конфигурации гипервизора.

← На главную