Почему 1С на PostgreSQL и Linux сильно тормозит при расчете зарплаты и проведении документов

При использовании сервера 1С:Предприятие 8.3 в связке с СУБД PostgreSQL на базе операционной системы Linux системные администраторы часто сталкиваются со значительным падением производительности. Типичный симптом: при подборе сотрудников, расчете зарплаты или проведении документа Начисление зарплаты работникам организаций в конфигурации 1С:ЗУП сервер тратит десятки минут, при этом загрузка процессора и оперативной памяти по ресурсам остается минимальной (5–10%). При этом файловый вариант той же базы работает в несколько раз быстрее.

Проанализируем основные причины возникновения подобного замедления и разберем по шагам технические способы решения проблемы.

Причина 1. Ошибки взаимодействия старых версий платформы 1С с СУБД PostgreSQL

В версиях платформы 1С:Предприятие от 8.3.5 до 8.3.7 имелись внутренние проблемы работы с плановиком запросов PostgreSQL. Из-за особенностей генерации SQL-запросов и работы с временными таблицами СУБД строила неоптимальные планы выполнения, что приводило к катастрофическому падению скорости при выполнении сложных расчетов зарплаты.

Начиная с релиза платформы 8.3.8.1444 и выше (в частности, на релизах линейки 8.3.10 и современнее), данные проблемы взаимодействия с PostgreSQL были полностью устранены.

Решение: обновим платформу 1С:Предприятие до актуального стабильного релиза (не ниже 8.3.10) и установим поддерживаемую сборку PostgreSQL (например, от Postgres Professional или Etersoft).

Причина 2. Ограничения 32-битной архитектуры (x86) и PAE

Использование 32-битной версии операционной системы и 32-битной СУБД PostgreSQL накладывает жесткие аппаратные ограничения. Даже если в ОС включен режим PAE (Physical Address Extension) и система суммарно видит 16 ГБ оперативной памяти, **один отдельно взятый процесс в 32-битной ОС Linux не может использовать более 2–3 ГБ виртуального адресного пространства**.

При попытке установить значение параметра shared_buffers в конфиге PostgreSQL больше 2 ГБ служба СУБД просто не сможет стартовать. В результате PostgreSQL не может эффективно использовать доступную оперативную память для кэширования таблиц и индексов, сбрасывая промежуточные результаты расчетов на диск.

Решение: перейдем на 64-битную операционную систему Linux и 64-битную версию СУБД PostgreSQL. Это позволит выделить под кэш СУБД необходимый объем памяти.

Причина 3. Неоптимальные параметры конфигурационного файла postgresql.conf

По умолчанию PostgreSQL поставляется с базовыми настройками, рассчитанными на работы в условиях крайне ограниченных ресурсов. Для эффективной обработки временных таблиц 1С и интенсивных расчетов необходимо скорректировать параметры в файле postgresql.conf.

Рассмотрим ключевые параметры и их значения для сервера с 16 ГБ ОЗУ:

# Основная память под кэш СУБД (25% от ОЗУ сервера)
shared_buffers = 4GB

# Оценка объема памяти, доступного для кэширования ОС и СУБД (50-75% от ОЗУ)
effective_cache_size = 8GB

# Память для операций обслуживающих процессов (VACUUM, CREATE INDEX)
maintenance_work_mem = 1GB

# Объем памяти под временные таблицы (крайне важно для 1С:ЗУП)
temp_buffers = 64MB

# Память для сортировок и группировок на каждую операцию
work_mem = 32MB

# Настройки журналирования и контрольных точек
checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 150

# Стоимость планировщика запросов
seq_page_cost = 0.1
random_page_cost = 0.4
cpu_operator_cost = 0.00025

После изменения параметров выполним перезапуск службы PostgreSQL:

sudo service postgresql restart

Причина 4. Энергосбережение процессора и настройки ядра Linux

Если процессоры сервера работают в энергосберегающих режимах, их частота автоматически снижается при выполнении однопоточных расчетов 1С, что приводит к низким результатам в тестах (например, в тесте Гилева).

Разберем по шагам оптимизацию оборудования и ОС:

1. BIOS/UEFI: переведем сервер в режим максимальной производительности (Performance mode), отключим состояния глубокого энергосбережения процессора (C-States) и включим Turbo Boost.
2. Режим работы ядер в Linux: установим регулятор частоты процессора в режим performance.
3. Отключение Transparent Huge Pages (THP): механизм THP в Ubuntu вызывает задержки выделения памяти для СУБД. Отключим его, добавив параметр transparent_hugepage=never в загрузчик Grub или выполнив команду: echo never > /sys/kernel/mm/transparent_hugepage/enabled
4. Оптимизация работы с диском и подкачкой (`/etc/sysctl.conf`): снизим агрессивность использования swap и настроим равномерную запись грязных страниц на диск:
   Скопировать код

   
   vm.swappiness = 1
   vm.dirty_background_ratio = 5
   vm.dirty_ratio = 10
   

Как использовать 32-битный аппаратный ключ HASP на 64-битной Linux

Частой причиной отказа системных администраторов от перехода на 64-битную ОС является наличие 32-битного USB-ключа защиты HASP. Существует два проверенных способа решения этой проблемы:

Способ A. Установка 32-битного драйвера HASP на 64-битную Ubuntu

Современные 64-битные дистрибутивы Linux поддерживают выполнение 32-битных приложений через мультиархитектурность. Для этого выполним команды:

sudo dpkg --add-architecture i386
sudo apt-get update
sudo apt-get install libc6:i386 lib32z1

После этого служба защиты haspd успешно запускается на 64-битной ОС и определяет физический USB-ключ.

Способ B. Вынос ключа защиты на отдельный узел сети

Физический ключ защиты не обязательно подключать непосредственно к серверу СУБД. Его можно установить в любой другой компьютер или виртуальную машину в локальной сети (например, под управлением Windows или 32-битной Linux) и запустить менеджер лицензий HASP License Manager.

На самом 64-битном сервере 1С останется лишь прописать IP-адрес хоста с ключом в файле конфигурации nethasp.ini:

[NH_TCPIP]
NH_SERVER_ADDR = 192.168.1.50 ; IP-адрес машины с USB-ключом
NH_TCPIP_METHOD = UDP

Такой подход позволяет полностью развернуть 64-битный сервер СУБД и 1С без риска потери работоспособности аппаратного ключа.