Развертывание серверной связки 1С:Предприятие + PostgreSQL на операционных системах семейства Linux — это отличное и высокоэффективное решение, которое позволяет сэкономить на лицензиях и получить гибкую управляемую среду. Однако администраторы часто сталкиваются с неочевидными проблемами производительности и стабильности. Типичный сценарий: база данных небольшая, документы проводятся и открываются мгновенно, но при попытке сформировать любой бухгалтерский отчет (например, Оборотно-сальдовую ведомость за месяц) процесс зависает навсегда, а рабочие процессы сервера 1С начинают перезапускаться.
В этой статье мы подробно разберем, почему возникает такая проблема, проанализируем узкие места серверного оборудования, изучим лог технологического журнала 1С и выясним, почему операционная система CentOS 7 может приводить к аварийному завершению процессов rphost, в то время как на Ubuntu Server все работает стабильно из коробки.
Рассмотрим классическую ситуацию, с которой сталкиваются многие системные администраторы при первичной настройке тестового или рабочего контура:
htop заметно, что в момент запуска отчета один из рабочих процессов 1С (rphost) начинает грузить процессорное ядро на 100%, после чего его идентификатор процесса (PID) внезапно меняется. Это свидетельствует о падении и аварийном перезапуске процесса операционной системой.Давайте пошагово проанализируем ключевые факторы, влияющие на такое поведение системы, и выработаем надежные методы их устранения.
Первое, на что необходимо обратить внимание при анализе производительности СУБД и сервера приложений, — это скорость работы дисков. При формировании отчетов СКД (Система компоновки данных) активно использует временные таблицы, выполняя колоссальное количество операций чтения и записи.
Если запустить простой тест записи на диск в CentOS с помощью утилиты dd:
dd if=/dev/zero of=/tmp/testfile bs=1G count=1 oflag=direct
И на выходе получить результат порядка 23,5 MB/c, то это сигнализирует о критических проблемах в дисковой подсистеме. Такая скорость сопоставима со старыми интерфейсами IDE и абсолютно неприемлема для систем автоматизации бизнес-процессов.
Проанализируем основные причины медленной работы дисков в виртуальной среде:
При выполнении сложных запросов с виртуальными таблицами 1С оптимизатор PostgreSQL иногда выбирает неоптимальный план выполнения запроса. Это связано с тем, что планировщик предполагает, будто подзапросы вернут небольшое количество строк, и решает использовать метод соединения вложенными циклами (Nested Loop).
На больших или специфически структурированных выборках вложенные циклы могут приводить к экспоненциальному росту времени выполнения запроса. Выясним, как ведет себя база данных при отключении этого метода соединения.
Попробуем внести изменение в конфигурационный файл postgresql.conf:
# Отключение использования вложенных циклов при планировании запросов
enable_nestloop = off
После изменения параметра необходимо перезапустить службу PostgreSQL:
systemctl restart postgresql-11
Важное примечание: Отключение enable_nestloop заставляет планировщик использовать более предсказуемые алгоритмы соединения (например, соединение хэшированием или слиянием — Hash Join, Merge Join). В ряде случаев это действительно спасает от «вечного» зависания отчетов, однако может незначительно снизить общую производительность простых запросов. Данную директиву стоит применять как диагностическую меру или временное решение до проведения полноценного анализа индексов и планов запросов с помощью команды EXPLAIN ANALYZE.
Если оптимизация дисков и отключение enable_nestloop не принесли результата, а процесс rphost продолжает перезапускаться при формировании отчета, необходимо настроить и изучить технологический журнал 1С. Рассмотрим типичную критическую ошибку, которая фиксируется в логах ТЖ перед падением процесса:
SYSTEM,3,process=rphost,p:processName=test,t:clientID=4,t:applicationName=1CV8C,t:computerName=Server-1C,t:connectID=24,SessionID=1,Usr=Администратор,AppID=1CV8C,level=ERROR,component=backend,class=ContainerAssembly ChildAccess,line=105,file=./src/MetadataChildAccess.cpp,func=getMDChildCount,childClassID=274bf899-db0e-4df6-8ab5-67bf6371ec0b,Context='Форма.Вызов : Отчет.ОборотноСальдоваяВедомость.Форма.ФормаОтчета.Модуль.СформироватьОтчетНаСервере
Проанализируем эту запись:
ContainerAssembly при вызове функции getMDChildCount в файле MetadataChildAccess.cpp.childClassID=274bf899-db0e-4df6-8ab5-67bf6371ec0b в архитектуре метаданных платформы «1С:Предприятие» жестко закреплен за объектами метаданных типа «Перерасчеты» (входящими в состав регистров расчета).rphost.Выясним, какие системные особенности CentOS 7 приводят к такому поведению и как их исправить.
Разберем основные причины несовместимости платформы 1С с окружением CentOS 7 при работе со сложными механизмами СКД и метаданными.
Платформа 1С критически чувствительна к языковому окружению. Если служба сервера 1С запускается в среде с локалью по умолчанию C или POSIX, разбор XML-схем и метаданных на русском языке завершается аварийно. В CentOS 7 службы, управляемые systemd, часто не наследуют пользовательские переменные окружения.
Для принудительного задания локали откроем конфигурационный файл службы 1С:
nano /etc/sysconfig/srv1cv83
Добавим в конец файла следующие строки:
LANG=ru_RU.UTF-8
LC_ALL=ru_RU.UTF-8
Убедимся, что сама локаль сгенерирована в системе. Для этого выполним команду:
locale -a | grep ru_RU
Если вывод пуст, сгенерируем локаль:
localedef -i ru_RU -f UTF-8 ru_RU.UTF-8
Система принудительного контроля доступа SELinux, включенная в CentOS 7 по умолчанию, блокирует попытки процессов 1С динамически компилировать код в оперативной памяти (JIT-компиляция, используемая СКД) и ограничивает доступ к временным каталогам.
Проверим текущий статус SELinux:
sestatus
Если режим указан как enforcing, переведем его в режим предупреждений (permissive) без перезагрузки сервера:
setenforce 0
Для окончательного отключения отредактируем конфигурационный файл:
nano /etc/selinux/config
Установим параметр:
SELINUX=permissive
При построении макета отчета СКД рассчитывает геометрические параметры ячеек на основе метрик шрифтов (Arial, Times New Roman, Calibri). Если этих шрифтов в Linux нет, графическая подсистема платформы пытается выполнить замену, что на старых библиотеках CentOS 7 часто вызывает сбой SIGSEGV.
Установим необходимые шрифты в систему:
yum install -y epel-release
yum install -y cabextract xorg-x11-font-utils
rpm -i https://downloads.sourceforge.net/project/mscorefonts2/rpms/msttcore-fonts-installer-2.6-1.noarch.rpm
После установки обязательно обновим кэш шрифтов в операционной системе:
fc-cache -fv
В CentOS 7 дефолтные лимиты на количество открытых файлов (файловых дескрипторов) и запущенных процессов для служб могут быть зажаты. При генерации сложных отчетов rphost открывает сотни временных файлов и порождает множество параллельных потоков.
Отредактируем unit-фаль службы 1С в systemd:
systemctl edit srv1cv83
Добавим в секцию [Service] следующие параметры:
[Service]
LimitNOFILE=infinity
LimitNPROC=infinity
Применим изменения конфигурации systemd и перезапустим службу 1С:
systemctl daemon-reload
systemctl restart srv1cv83
Если выполнение всех вышеперечисленных шагов на CentOS 7 вызывает затруднения или архитектурные ограничения старого ядра Linux (в CentOS 7 по умолчанию используется ядро 3.10 и устаревшие библиотеки glibc 2.17 и libicu 50.2) не позволяют добиться стабильности, наиболее разумным решением будет миграция на современный дистрибутив — например, Ubuntu Server 18.04 LTS или 20.04 LTS.
Проанализируем, почему на Ubuntu Server эта проблема не воспроизводится:
glibc 2.27+ и libicu 60+. В них исправлены многие утечки памяти и критические ошибки обработки бинарных данных, что исключает сбой getMDChildCount при обходе метаданных 1С.apt install ttf-mscorefonts-installer.Практический опыт показывает: переход на Ubuntu Server позволяет полностью избавиться от зависаний при компоновке отчетов без необходимости тонкой ручной отладки системных библиотек CentOS 7.