Переход с привычной связки Windows Server + MSSQL на импортонезависимый стек Astra Linux + PostgreSQL часто сопровождается неприятными сюрпризами. Одной из самых острых проблем является катастрофическое падение производительности в «тяжелых» операциях, таких как проведение или распроведение документов в старых конфигурациях (например, УПП). Рассмотрим ситуацию, когда сервер на Linux, будучи в два раза мощнее старого «железа», выполняет операцию за 6 часов вместо 2 минут. Проанализируем причины этого явления, проведем замер производительности контура 1С и поиск узких мест и разберем по шагам методы оптимизации системы.
Разберем основные факторы, которые приводят к деградации скорости. Чтобы лучше понять внутренние процессы, полезно проанализировать SQL сервер глазами 1С-ника. В отличие от MSSQL, планировщик PostgreSQL иначе строит планы запросов. Основная проблема часто заключается в использовании Nested Loop (вложенных циклов) там, где эффективнее было бы использовать Hash Join. Кроме того, современные версии PostgreSQL (14, 15) включают по умолчанию механизмы, которые могут «зависать» на специфических запросах 1С.
Проанализируем типичный лог медленного запроса к регистрам бухгалтерии (поможет инструментарий для анализа запросов, метаданных и отладки 1С):
UPDATE _AccRgAT11724 SET _Fld1703 = _AccRgAT11724._Fld1703 + T2._Fld1703
FROM pg_temp.tt8 T2
WHERE (T2._Period = _AccRgAT11724._Period AND T2._AccountRRef = _AccRgAT11724._AccountRRef
AND T2._Fld1701RRef = _AccRgAT11724._Fld1701RRef ... )
Такие запросы при распроведении документа обновляют итоги. Если СУБД выбирает неверный метод соединения с временной таблицей pg_temp.tt8, время выполнения растет экспоненциально. Выясним, как это исправить.
Рассмотрим файл postgresql.conf. Стандартные настройки (дефолтные) рассчитаны на совместимость, а не на высокую производительность 1С. Проанализируем ключевые параметры, которые необходимо изменить:
jit часто тратит на компиляцию плана запроса 1С больше времени, чем на само выполнение. Установим: jit = off.random_page_cost должен быть близок к seq_page_cost. Установим: random_page_cost = 1.1. Это заставит планировщик чаще использовать индексы. Дополнительно оптимизировать структуру можно, используя генератор скрипта для индексации таблиц базы данных PostgreSQL.effective_cache_size должен составлять около 75% всей оперативной памяти, а shared_buffers — порядка 25%.enable_memoize = off.Посмотрим на пример правильного блока кастомизированных настроек:
# Основные настройки для 1С
shared_buffers = 64GB # 25% от 256GB
effective_cache_size = 192GB # 75% от 256GB
work_mem = 512MB
maintenance_work_mem = 2GB
random_page_cost = 1.1
jit = off
max_locks_per_transaction = 1000
escape_string_warning = off
standard_conforming_strings = off
Проанализируем ситуацию с «железом». При подготовке сервера важно учитывать особенности настройки Astra Linux с установкой зависимостей для корректной работы платформы. Если у вас многопроцессорная система (например, 2 сокета), важную роль играет NUMA (Non-Uniform Memory Access). Если ядро Linux пытается балансировать память между процессорами во время работы 1С, это вызывает огромные задержки. Попробуем отключить numa_balancing на уровне ядра:
sysctl -w kernel.numa_balancing=0
Также разберем работу процессора. В Linux по умолчанию может быть включен режим энергосбережения powersave. Нам необходимо перевести все ядра в режим performance. Рассмотрим команду для проверки и установки режима:
# Установка режима максимальной производительности
cpupower frequency-set -g performance
Выясним интересный нюанс: общение между сервером 1С (кластером) и PostgreSQL через localhost (TCP/IP) медленнее, чем через Unix Domain Sockets. Это связано с накладными расходами сетевого стека. Чтобы ускорить обмен данными, в строке подключения в консоли администрирования 1С вместо localhost или 127.0.0.1 укажем путь к сокету, обычно это /var/run/postgresql или просто адрес директории.
Посмотрим, как настроить права доступа в pg_hba.conf для такого подключения:
# Разрешаем подключение через сокеты для всех баз
local all all trust
Поскольку УПП активно использует временные таблицы при проведении (что мы и видели в логе pg_temp.tt8), их размещение критично — поможет ускорение группового проведения документов и закрытия периода. Рассмотрим возможность выноса временных файлов в оперативную память (RAM-диск). Для этого создадим директорию в tmpfs и укажем её в настройках Postgres.
Также проанализируем настройки расширения online_analyze. Если оно включено, оно может запускать ANALYZE прямо внутри вашей транзакции распроведения документа, что блокирует работу. В высоконагруженных системах лучше установить online_analyze.enable = off и настроить регламентное задание на ANALYZE всей базы в часы минимальной нагрузки. Для упрощения этих задач рекомендуем использовать обслуживание баз данных 1C на Postgresql под Astra Linux.
Разберем влияние Astra Linux Special Edition. В этой системе работают механизмы мандатного контроля доступа (MAC) и аудита. Если включен расширенный аудит файловых операций, каждое чтение/запись данных Postgres будет записываться в системный лог безопасности. Это может замедлить дисковые операции в разы.
Рекомендация: Проверьте параметры parsec и убедитесь, что аудит для папки с данными PostgreSQL (`/var/lib/postgresql/data`) настроен без избыточной детализации. Используйте опцию монтирования noatime для дисков с базой, чтобы система не тратила ресурсы на обновление времени последнего доступа к файлам.
Подведем итог нашему исследованию. Для достижения приемлемой скорости в 1С на Astra Linux недостаточно просто «дать больше памяти». Необходимо:
jit и оптимизировать random_page_cost.performance для CPU и отключить numa_balancing.ANALYZE базы после миграции.Соблюдение этих шагов позволит сократить время выполнения операций с нескольких часов до считанных минут.