Как работает сервер 1С на Linux

Сервер 1С:Предприятия на Linux — это набор системных процессов, которые принимают подключения от клиентских приложений, выполняют прикладной код конфигурации и обмениваются данными с СУБД, чаще всего PostgreSQL. В отличие от файлового режима, где база лежит в каталоге и обслуживается самой платформой, клиент-серверный вариант разделяет нагрузку: Linux-машина отвечает за вычисления и бизнес-логику, а СУБД — за хранение и транзакции.

Архитектурно сервер 1С на Linux почти идентичен Windows-версии: используются те же исполняемые файлы, тот же протокол взаимодействия с клиентами и тот же формат кластера. Различия касаются путей установки, механизма служб (systemd вместо служб Windows), прав доступа к файлам и специфики драйверов СУБД. Для администратора это означает, что большинство приёмов диагностики переносится между платформами без изменений.

Типичный сценарий внедрения выглядит так: на отдельной Linux-машине разворачивается сервер 1С и PostgreSQL (либо СУБД выносится на отдельный хост), создаётся кластер с информационными базами, клиенты подключаются по сети через тонкий, толстый или веб-клиент. Ниже разобраны компоненты, порядок установки, настройка и контроль работоспособности.

Из каких компонентов состоит сервер 1С

Кластер серверов 1С — это логическое объединение рабочих процессов, которое клиент видит как единую точку подключения. Минимальный кластер состоит из одного сервера, но в него можно добавлять дополнительные машины для распределения нагрузки и отказоустойчивости.

Ключевые процессы:

• ragent — агент сервера. Слушает сетевой порт (по умолчанию 1540), принимает входящие подключения клиентов и консолей администрирования, хранит реестр кластера.
• rmngr — менеджер кластера. Управляет составом кластера, распределяет клиентские соединения между рабочими процессами, отслеживает их состояние.
• rphost — рабочий процесс. Именно в нём исполняется код конфигурации, выполняются запросы к СУБД, обслуживаются сеансы пользователей. Таких процессов может быть несколько.

Дополнительно в кластере может работать процесс rfagent (агент файловых потоков) на вспомогательных серверах. Все данные о составе кластера, информационных базах и настройках хранятся в каталоге реестра — по умолчанию /home/usr1cv8/.1cv8/1C/1cv8 (каталог зависит от пользователя, под которым запущен агент).

Как проходит запрос от клиента к базе данных

Понимание цепочки обработки запроса помогает локализовать проблемы производительности. Когда пользователь открывает документ в тонком клиенте, происходит следующее: клиент устанавливает соединение с агентом сервера, агент через менеджер кластера назначает сеансу рабочий процесс rphost, и дальше клиент общается уже с ним.

Рабочий процесс исполняет встроенный язык конфигурации, а когда требуется чтение или запись данных — формирует SQL-запросы к СУБД через соответствующий клиентский драйвер. Результат возвращается по той же цепочке в обратном порядке. Платформа сама транслирует обращения встроенного языка в диалект конкретной СУБД, поэтому один и тот же код работает и с PostgreSQL, и с MS SQL, и с Oracle.

Важное следствие: узким местом может оказаться любой участок цепочки — сеть между клиентом и сервером, нехватка памяти у rphost, медленные запросы на стороне PostgreSQL или дисковая подсистема СУБД. Диагностику всегда стоит вести по сегментам, а не «в целом по системе».

Установка сервера 1С на Linux

Дистрибутив сервера 1С для Linux распространяется в виде deb- или rpm-пакетов, а также архива для ручной установки. Порядок действий для deb-based систем (например, Debian или Ubuntu) выглядит так: скачивается комплект пакетов сервера нужной версии платформы, устанавливаются зависимости, затем сами пакеты.

Типовая последовательность установки:

1. 1
   Скачайте дистрибутив сервера 1С для Linux нужной версии платформы с официального портала
2. 2
   Установите пакеты командой dpkg -i *.deb (или rpm -ivh для rpm-систем)
3. 3
   Убедитесь, что создан пользователь usr1cv8 и каталоги платформы
4. 4
   Запустите агент сервера: systemctl start srv1cv8 (имя службы зависит от версии)
5. 5
   Проверьте, что процессы ragent и rmngr запущены: ps aux | grep 1cv8
6. 6
   Подключитесь к кластеру через консоль администрирования и создайте информационную базу

После установки агент обычно регистрируется как служба systemd и может запускаться автоматически. Если служба не создана, агент можно запустить вручную с указанием порта и каталога реестра, но для постоянной эксплуатации правильнее оформить unit-файл systemd с автозапуском и перезапуском при сбое.

sudo dpkg -i 1c-enterprise-<em>-server_</em>.deb
sudo systemctl enable --now srv1cv8-8.3.24-*.service
ps aux | grep -E 'ragent|rmngr|rphost'

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

Связка с PostgreSQL и другими СУБД

Сервер 1С сам по себе не хранит данные информационных баз — за это отвечает внешняя СУБД. На Linux чаще всего используется PostgreSQL, поскольку для него существуют сборки, адаптированные под требования платформы 1С (специфические настройки и патчи). Стандартный PostgreSQL из репозитория дистрибутива может работать некорректно или с пониженной производительностью, поэтому обычно ставят рекомендованную сборку.

При создании информационной базы в консоли кластера указываются: тип СУБД, имя сервера баз данных, имя базы, пользователь и пароль. Сервер 1С подключается к PostgreSQL от имени этого пользователя и создаёт структуру таблиц автоматически — вручную создавать схему не нужно, достаточно пустой базы с правильными параметрами (локаль, кодировка).

Практические требования к связке:

• пользователь СУБД должен иметь права на создание таблиц и индексов в своей базе;
• параметры PostgreSQL (память, количество соединений, настройки autovacuum) нужно настраивать под нагрузку, значения по умолчанию рассчитаны на слабое оборудование;
• сервер 1С и СУБД желательно размещать на разных машинах при заметной нагрузке, чтобы процессы не конкурировали за память;
• резервное копирование делается средствами СУБД (pg_dump или физические копии), а не копированием файлов платформы.

Администрирование кластера: консоль и утилита rac

Управлять кластером можно двумя способами. Первый — графическая консоль «Администрирование серверов 1С:Предприятия», которая работает под Windows и подключается к агенту по сети. Через неё создаются и удаляются информационные базы, настраиваются рабочие процессы, просматриваются сеансы и соединения, задаются блокировки сеансов на время регламентных работ.

Второй способ — консольная утилита rac, входящая в состав сервера. Она позволяет автоматизировать операции скриптами: получить список сеансов, завершить сеанс, установить блокировку, выгрузить список баз. Для работы rac требуется аутентификация администратора кластера, если она настроена.

/opt/1cv8/x86_64/8.3.24.*/rac session list --cluster=<ID_кластера> --cluster-user=Админ --cluster-pwd=пароль

Из практических функций консоли особенно полезны: принудительное завершение зависших сеансов, установка блокировки начала сеансов с сообщением пользователям перед обновлением конфигурации, настройка требований назначения функциональности (какие сервисы на каких серверах кластера запускать) и параметры перезапуска рабочих процессов.

Настройка перезапуска рабочих процессов

Рабочие процессы rphost со временем накапливают потребление памяти, особенно при активной работе с большими выборками. В свойствах рабочего сервера в консоли можно задать допустимый объём памяти и интервал перезапуска процессов. Платформа при этом плавно переводит сеансы на другие процессы, и пользователи не замечают перезапуска. Оставлять процессы без перезапуска на недели — частая причина постепенной деградации производительности.

Логи, технологический журнал и диагностика

Основной инструмент диагностики — технологический журнал (ТЖ). Он включается созданием конфигурационного файла logcfg.xml в каталоге conf платформы. В файле задаются собираемые события: длительные запросы к СУБД, ошибки, взаимоблокировки, события памяти, длительные вызовы. Журнал пишется в указанный каталог в виде текстовых файлов, ротируемых по времени.

Минимальный рабочий подход: включить сбор событий DBPOSTGRS (запросы к PostgreSQL) с фильтром по длительности и события EXCP (исключения). Это позволяет найти медленные запросы и ошибки без чрезмерного объёма логов. Полный сбор всех событий на нагруженном сервере быстро заполнит диск, поэтому ТЖ настраивают избирательно.

Помимо ТЖ полезны системные средства Linux: top и htop для загрузки CPU и памяти по процессам, iostat для дисковой нагрузки, журнал службы через journalctl -u имя_службы для ошибок запуска агента. Связка «системные метрики + технологический журнал + логи PostgreSQL» покрывает практически все типовые проблемы.

Типовые проблемы и способы их решения

Самая частая жалоба — «1С тормозит». Алгоритм разбора: сначала проверить загрузку CPU и памяти на сервере 1С и на сервере СУБД, затем посмотреть длительные запросы в технологическом журнале, затем — блокировки. В большинстве случаев причина оказывается в неоптимальных запросах прикладного кода или в неправильно настроенном PostgreSQL, а не в самой платформе.

Вторая группа проблем — недоступность кластера: клиенты не подключаются. Проверяется, запущен ли ragent, слушает ли он порт (например, ss -tlnp | grep 1540), не блокирует ли соединения межсетевой экран, не переполнен ли диск с реестром кластера. После аварийного отключения питания иногда повреждаются файлы реестра — поэтому каталог реестра стоит включать в резервное копирование.

Третья группа — ошибки лицензирования: сервер не находит лицензию после обновления платформы или изменения железа. Лечится повторной активацией лицензии или установкой сервера HASP для аппаратных ключей, если используются USB-ключи.

Часто задаваемые вопросы