Как обеспечить 99,9% доступности кластера 1С на Linux: DevOps, CI/CD и контроль памяти rphost.

01.09.26

База данных - HighLoad оптимизация

+1 –
Практическое руководство по построению устойчивого DevOps-контура для 1С на Linux: от сборки и CI/CD до эксплуатации кластера под нагрузкой. В статье разобраны ключевые узкие места, которые чаще всего приводят к сбоям: разрыв форматов EDT и Конфигуратора, ложноположительные «успешные» сборки, особенности запуска 1С в Docker, ограничения лицензий ПРОФ/КОРП и рост памяти rphost/rmngr. Показаны инженерные подходы к повышению доступности: многоступенчатая валидация пайплайна, корректная работа с логами и кодировками, мониторинг, safe-ротация процессов, внешняя оркестрация через systemd/скрипты и сценарии реагирования на инциденты. В результате вы получаете набор готовых практик и шаблонов для перехода от ручного администрирования к предсказуемой, отказоустойчивой эксплуатации 1С на Linux.

Файлы

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование Скачано Купить файл
Как обеспечить 99,9% доступности кластера 1С на Linux: DevOps, CI/CD и контроль памяти rphost
.zip 5,10Kb
0 2 500 руб. Купить

Подписка PRO — скачивайте любые файлы со скидкой до 85% из Базы знаний

Оформите подписку на компанию для решения рабочих задач

Оформить подписку и скачать решение со скидкой

Вы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

Как обеспечить 99,9% доступности кластера 1С на Linux: DevOps, CI/CD и контроль памяти rphost

Сквозное инженерное руководство по построению детерминированного сборочного конвейера, контролю сетевого лицензирования, безопасной диагностике памяти и автоматическому Self-Healing в среде Linux.

Преодоление разрыва EDT Конфигуратор, 5 рубежей обороны от False Success, разбор феномена "перестарков" и готовые шаблоны Infrastructure as Code

Эксплуатация "1С:Предприятия 8.3" на Linux долгое время напоминала чёрную магию: хрупкие инсталляции, ручные обновления баз через RDP во внерабочее время, зависающие модальные окна в пакетном режиме Конфигуратора и рабочие процессы rphost, неконтролируемо поглощающие оперативную память вплоть до принудительного вызова OOM-killer. Когда объемы баз данных перешагивают терабайтные отметки, а бизнес требует непрерывности 24/7, эксплуатация 1С обязана превратиться в детерминированный инженерный процесс Infrastructure as Code (IaC).

Ниже собран инженерный каркас непрерывного цикла разработки, сборки и промышленной эксплуатации 1С на Linux: преодоление архитектурного разрыва форматов, защита от феномена "ложного успеха" (False Success) в CI/CD, тонкости лицензирования в контейнерах, низкоуровневая анатомия памяти rphost и безопасная оркестрация кластера без сбоев в проде.

Артефакты к статье (вынесены в отдельные файлы):
  • architecture-flow.txt
  • nethasp.ini
  • license-memory-flow.txt
  • bsl-temporary-storage-cleanup.bsl
  • bsl-safe-batching.bsl
  • rotation-timer-flow.txt
  • admincluster-monitor@.service
  • admincluster-monitor@.timer
  • Dockerfile
  • 1c-ci-linux-build-v4.sh
  • logcfg.xml
Оглавление:
  1. Архитектурный разрыв: 1C:EDT Конфигуратор
  2. CI/CD на Linux: 5 рубежей обороны против "Ложного успеха" (False Success)
  3. Докеризация 1С и лицензионный барьер в контейнерах
  4. Анатомия памяти 1С: rphost, rmngr и лицензионная пропасть (ПРОФ vs КОРП)
  5. Анатомия "Мертвого кэша": Причины утечек памяти на уровне BSL
  6. Мифы о C++ дампах памяти и настройка logcfg.xml
  7. Внешняя оркестрация: Проект AdminClusterMonitor
  8. Сборочный пакет: Готовые артефакты (IaC)
  9. План перехода на промышленный DevOps за 4 недели

1. Архитектурный разрыв: 1C:EDT Конфигуратор

При внедрении современной инженерной культуры команды неизбежно сталкиваются с разрывом форматов: разработчики ведут работу в среде 1C:Enterprise Development Tools (EDT), фиксируя в Git дерево структурированных XML-файлов и модулей Eclipse, тогда как рантайм платформы исполняет бинарные контейнеры конфигураций (.cf) и расширений (.cfe).

Попытка использовать утилиты ring (модуль EDT CLI) или ibcmd (автономный сервер) как изолированные консольные компиляторы наталкивается на фундаментальные ограничения архитектуры платформы:

Схема путей трансляции и компиляцииImage
Схема путей трансляции и компиляции
  • Утилита ring - диспетчер трансляции, а не компилятор. Сама по себе утилита ring является Java-оболочкой и менеджером плагинов. Команда ring edt workspace export выполняет лишь конвертацию метаданных: преобразует проект EDT в дерево XML-файлов формата выгрузки Конфигуратора. Среда EDT не имеет встроенного механизма упаковки исходников в бинарный контейнер рантайма.
  • Ограничения утилиты ibcmd. Автономный сервер (ibcmd infobase config import) позволяет собирать конфигурации без развертывания полнофункционального кластера серверов, но не является изолированным компилятором. Ему требуется физическая база данных (параметр --data для файловой СУБД). Утилита инициализирует таблицы на диске, сериализует метаданные и лишь затем дает выгрузить бинарник.
  • Различие по графической подсистеме. Исполняемый файл 1cv8 в пакетном режиме (DESIGNER) исторически завязан на библиотеки рендеринга и оконную подсистему (требует Xvfb, системные шрифты, dbus). Утилита ibcmd функционирует в чистом безголовом (headless) режиме, позволяя собирать легковесные сборочные образы без графического стека.

Архитектурный вывод:

В экосистеме 1С отсутствует концепция бессерверного компилятора исходников. Автоматизированный CI/CD пайплайн обязан брать на себя полный цикл: трансляцию через EDT CLI, инициализацию временной файловой базы на быстром накопителе, пакетный импорт метаданных и гарантированное уничтожение временных ресурсов после сборки.

2. CI/CD на Linux: 5 рубежей обороны против "Ложного успеха" (False Success)

Пакетный режим Конфигуратора 1С под Linux коварен: процесс может упасть из-за проблем с лицензированием или содержать критические ошибки синтаксиса, но при этом вернуть операционной системе успешный код завершения 0. Механизм динамической компиляции платформы маскирует дефектный код вплоть до первого обращения пользователя в проде.

Для исключения дефектных поставок сборочный процесс должен опираться на 5 рубежей инженерной защиты:

Рубеж В чём заключается скрытая опасность Инженерное решение в пайплайне
Слой 1: Нормализация и BOM Платформа пишет лог /Out в UTF-16LE, CP1251 или UTF-8 с BOM. Поиск утилитой grep по UTF-16 в UTF-8 окружении не вернет совпадений - пайплайн завершится ложно-зеленым. Определение кодировки на лету через file -b --mime-encoding, конвертация через iconv в чистый UTF-8 и удаление маркерного байта: sed -i '1s/^\xEF\xBB\xBF//'.
Слой 2: Валидация лога При сбоях до старта ядра (сетевой разрыв, отказ службы лицензирования) лог создается с нулевым размером. Проверка пустых файлов дает вердикт "ошибок нет". Проверка размера и наличия лога [[ -s "$LOG_FILE" ]] перед парсингом. Если файл пуст - пайплайн немедленно завершается с выводом системного stderr.
Слой 3: POSIX Regex Парсинг только подстроки "Ошибка" пропускает сообщения англоязычной локали ОС или среды выполнения (Error, Expected, Undefined). Мультиязычное регулярное выражение компилятора:
"ошибка|неопознан|ожидается|не определен|error|expected|undefined|not found".
Слой 4: Изоляция сессий Параллельный запуск раннеров на общем хосте сборки приводит к взаимной перезаписи артефактов и логов. Генерация уникального RUN_ID на базе таймстемпа и генератора энтропии. Изоляция артефактов в /tmp/ и обязательный перехватчик trap cleanup EXIT.
Слой 5: Diff-верификация Успешный синтаксический контроль не гарантирует, что метаданные в СУБД эквивалентны исходникам в коммите Git. Обратная выгрузка конфигурации из БД (/DumpConfigToFiles) и рекурсивный diff -r с каталогом Git с флагом --strip-trailing-cr (исключая динамический ConfigDumpInfo.xml).
Ловушка брошенных блокировок (.1cLck): Если предыдущая сборка была прервана ядром ОС по OOM или тайм-ауту, в каталоге базы остаются файлы *.1cLck и 1Cv8.lk. Следующий запуск упадет из-за невозможности монопольного захвата базы. Перед стартом сборочный скрипт обязан проверять отсутствие активных процессов 1cv8 через pgrep и зачищать зависшие lock-файлы.

3. Докеризация 1С и лицензионный барьер в контейнерах

Развертывание сборочных агентов и серверов приложений 1С в Docker на Linux требует жесткого разделения стратегий работы с лицензиями:

Параметр Сетевой аппаратный ключ (HASP) Программные лицензии (*.lic)
Топология Выделенный сервер с HASP License Manager (порт UDP 475). Монтирование каталога /var/1C/licenses с хост-системы.
Режим сети Docker Стандартный bridge или overlay-сеть с маршрутизацией. Строго --net=host.
Риски деактивации Потеря UDP-пакетов при широковещательном broadcast-поиске. Сброс лицензии из-за генерации виртуального MAC-адреса.
Инженерное решение Монтирование преднастроенного nethasp.ini с прямым IP. Монтирование в режиме :ro, строгая фиксация hostname.

Конфигурация nethasp.ini для исключения сетевых задержек

Ini - nethasp.iniUTF-8Открыть файл
1 [NH_COMMON]
2 NH_TCPIP = Enabled
3  
4 [NH_TCPIP]
5 NH_SERVER_ADDR = 192.168.1.50 ; Статический IP-адрес HASP License Manager
6 NH_PORT_NUMBER = 475
7 NH_TCPIP_METHOD = UDP
8 NH_USE_BROADCAST = Disabled ; Запрет широковещания, исключающий сетевые таймауты
Важно при работе с программными лицензиями (*.lic): Механизм защиты программной лицензии 1С рассчитывает хеш оборудования, куда входят MAC-адрес сетевого интерфейса, UUID материнской платы, BIOS и Hostname хоста. Запуск контейнера в стандартном bridge-режиме генерирует новый виртуальный сетевой интерфейс со случайным MAC-адресом, что приводит к инвалидации лицензии. Для контейнеров с программными лицензиями допустимо использовать только сетевой стек хоста: docker run --net=host -v /var/1C/licenses:/var/1C/licenses:ro ....

4. Анатомия памяти 1С: rphost, rmngr и лицензионная пропасть (ПРОФ vs КОРП)

В инженерной среде до сих пор циркулируют вредные заблуждения касательно внутреннего устройства рантайма 1С:

  • Миф 1: "Процесс rphost работает под JVM и управляется Garbage Collector".
    Реальность: Исполняемые файлы rphost, rmngr, ragent - это нативные бинарные сборки C++. Никакой JVM или CLR внутри нет. Мониторинг метрик JVM и механизмы GC к ним неприменимы в принципе. Аллокация и освобождение памяти выполняются напрямую через системные вызовы ядра Linux (glibc malloc / mmap).
  • Миф 2: "rmngr потребляет пренебрежимо мало ресурсов, контролировать нужно только rphost".
    Реальность: Менеджер кластера rmngr хранит сеансовые данные, глобальные блокировки, распределение транзакций и очереди фоновых заданий. Утечка памяти в rmngr приводит к падению кластера с тем же эффектом, что и деградация рабочих процессов.
  • Миф 3: "В Linux достаточно мониторить RSS процесса".
    Реальность: При включенном swap ядро операционной системы вытесняет неактивные страницы кучи 1С на диск. Метрика Resident Set Size (vmRSS) падает, создавая ложное впечатление "освобождения" памяти, в то время как кластер впадает в глубокий ступор из-за задержек дискового I/O. Реальное потребление процесса отражает только сумма vmRSS и vmSwap.

Лицензионный барьер управления памятью

Возможность платформы штатно перезапускать рабочие процессы без деградации пользовательских сессий зависит от уровня лицензии кластера:

Лицензионное ветвление оркестрации памятиImage
Лицензионное ветвление оркестрации памяти

Сценарий КОРП: Нативная автоматическая ротация

Кластер уровня КОРП позволяет настроить плавный перезапуск процессов через консоль администрирования или утилиту rac:

  • --temporary-memory-limit - предельный объем виртуальной памяти (по умолчанию 0 = 80% RAM хоста). При превышении процесс переводится в статус "Не использовать" и прекращает принимать новые соединения.
  • --memory-excess-time - допустимое время превышения порога. По умолчанию равно 0 (автоматическая ротация отключена!). Для активации механизма перезапуска здесь должно быть выставлено положительное значение (например, 300 секунд).
  • --safe-memory-usage-per-call - безопасный объем памяти на один серверный вызов. Если пользовательский код инициирует неоптимальную выборку, платформа прерывает конкретный вызов с генерацией исключения в BSL, сохраняя процесс rphost и сеансы остальных пользователей в рабочем состоянии.

Сценарий ПРОФ: Внешняя оркестрация и ограничения cgroups

На лицензиях ПРОФ кластер серверов игнорирует любые параметры лимитов памяти, заданные через rac или оснастку.

Попытка жестко ограничить память контейнера через Docker-параметр mem_limit (механизм Linux cgroups) приводит к тому, что ядро при достижении лимита уничтожает rphost по SIGKILL, мгновенно обрывая сотни активных транзакций. Для лицензий ПРОФ единственным безопасным решением остается внешняя оркестрация через RAS API.

5. Анатомия "Мертвого кэша": Причины утечек памяти на уровне BSL

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

  • Штатный прогрев: Рост памяти в первые часы после перезапуска службы за счет кэширования скомпилированных модулей, метаданных и прав доступа. Рост выходит на плато.
  • Утечка памяти: Непрерывный ступенчатый рост объема Commit/Private Bytes, который не прекращается при отсутствии пользовательской активности (например, ночью при отключенных регламентных заданиях).

Чек-лист типовых источников утечек памяти в 1С

  1. Пулы сеансов HTTP-сервисов и Web-сервисов.
    Сеанс сервиса после возврата ответа не уничтожается, а засыпает в пуле для повторного использования. Любые неочищенные переменные модулей и временные таблицы продолжают удерживаться в оперативной памяти до физической утилизации сеанса сервером.
  2. Временное хранилище без привязки к UUID формы.
    Вызов метода ПоместитьВоВременноеХранилище(Данные) без указания уникального идентификатора контекста связывает данные со временем жизни сеанса:
    BSL - Очистка временного хранилищаUTF-8Открыть файл
    1 // ПРАВИЛЬНО: Привязка ко времени жизни клиентской формы
    2 АдресХранилища = ПоместитьВоВременноеХранилище(ТаблицаДанных, ЭтаФорма.УникальныйИдентификатор);
    3  
    4 // ПРАВИЛЬНО: Явная зачистка в фоновых заданиях и HTTP-сервисах
    5 УдалитьИзВременногоХранилища(АдресХранилища);
  3. Мутабельные коллекции в параметрах кэшируемых функций.
    Передача мутабельных объектов (Массив, Структура, ТаблицаЗначений) в параметры функций общих модулей с признаком "Повторное использование возвращаемых значений" заставляет платформу рассчитывать хеш и создавать дубликаты кэша при каждой модификации переданной коллекции.
  4. Отсутствие батчинга в циклических транзакциях.
    Накопление транзакционного контекста при обработке больших массивов данных без промежуточных фиксаций приводит к разрастанию приватной памяти процесса:
    BSL - Безопасный батчинг с защитой от DeadlockUTF-8Открыть файл
    1 РазмерПачки = 500;
    2 Счетчик = 0;
    3  
    4 НачатьТранзакцию();
    5 Попытка
    6     Пока Выборка.Следующий() Цикл
    7         Объект = Выборка.ПолучитьОбъект();
    8         // ... Модификация объекта
    9         Объект.Записать();
    10         Счетчик = Счетчик + 1;
    11         Если Счетчик % РазмерПачки = 0 Тогда
    12             ЗафиксироватьТранзакцию(); // Сброс блокировок и буфера транзакции
    13             НачатьТранзакцию();
    14         КонецЕсли;
    15     КонецЦикла;
    16     Если ТранзакцияАктивна() Тогда
    17         ЗафиксироватьТранзакцию();
    18     КонецЕсли;
    19 Исключение
    20     Если ТранзакцияАктивна() Тогда
    21         ОтменитьТранзакцию();
    22     КонецЕсли;
    23     ЗаписьЖурналаРегистрации("ПакетнаяОбработка", УровеньЖурналаРегистрации.Ошибка,,, ОписаниеОшибки());
    24     ВызватьИсключение;
    25 КонецПопытки;
Эффект Cache Stampede: Метод ОбновитьПовторноИспользуемыеЗначения(), вызванный в продуктивной базе в разгар рабочего дня, одномоментно инвалидирует кэши всех сеансов. Сотни клиентских процессов одновременно инициируют перерасчет структур метаданных, приводя к мгновенной полке в 100% CPU на сервере приложений.

6. Мифы о C++ дампах памяти и настройка logcfg.xml

Среди системных администраторов часто встречается рекомендация настраивать генерацию полных дампов rphost через gcore или procdump -ma. На боевом сервере такой подход создает две критические проблемы:

  1. Заморозка продуктивной базы. Утилита gcore приостанавливает выполнение всех потоков процесса на время сброса страниц памяти на диск (системный вызов ptrace). Сброс дампа процесса размером 64 ГБ подвешивает базу на 30–60 секунд, вызывая лавинообразный обрыв клиентских сеансов по таймауту.
  2. Бесполезность без отладочных символов (PDB). Вендор не публикует публичные символы отладки ядра платформы. Анализ дампа в GDB или WinDbg покажет лишь адреса инструкций в скомпилированных бинарниках 1cv8 без возможности связать их с конкретным общим модулем или строкой в коде 1С. Такие дампы имеют ценность исключительно для вендора в рамках официального расследования ошибок платформы.

Для выявления тяжелых вызовов на уровне прикладного кода основным инструментом остается Технологический журнал 1С (logcfg.xml).

Фильтрация событий CALL и SCALL по объему памяти от 100 МБ помогает отлавливать тяжелые разовые вызовы, но бессильна против микроутечек (по 100 КБ за вызов), возникающих миллионы раз в сутки.

7. Внешняя оркестрация: Проект AdminClusterMonitor

Для безопасного управления рабочими процессами на лицензиях ПРОФ и предотвращения фрагментации памяти применяется метод внешней оркестрации через опрос RAS API (подход AdminClusterMonitor).

Охота на "Перестарков" (Stale Processes)

"Перестарок" - это рабочий процесс rphost, время жизни которого превысило заданный интервал (например, 24 часа), при этом количество активных соединений на нем опустилось до нуля (Connections == 0). Процесс удерживает фрагментированную память, но фактически простаивает:

Алгоритм работы таймера ротацииImage
Алгоритм работы таймера ротации

Конфигурация systemd для регламентной очистки кластера

Шаблон юнита службы (/etc/systemd/system/admincluster-monitor@.service):

Ini - admincluster-monitor@.serviceUTF-8Открыть файл
1 [Unit]
2 Description=AdminClusterMonitor service for profile %i
3 After=network.target
4  
5 [Service]
6 Type=simple
7 User=usr1cv8
8 Group=grp1cv8
9 EnvironmentFile=/etc/admincluster/config.conf
10 ExecStart=/opt/admincluster/admincluster_run.sh --profile %i
11 StandardOutput=journal
12 StandardError=journal
13 SyslogIdentifier=admincluster-monitor-%i
14 Restart=on-failure

Шаблон таймера (/etc/systemd/system/admincluster-monitor@.timer):

Ini - admincluster-monitor@.timerUTF-8Открыть файл
1 [Unit]
2 Description=Hourly trigger for AdminClusterMonitor profile %i
3  
4 [Timer]
5 OnBootSec=5min
6 OnUnitActiveSec=1h
7 Persistent=true
8  
9 [Install]
10 WantedBy=timers.target

8. Сборочный пакет: Готовые артефакты (IaC)

1. Промышленный Dockerfile сборочного раннера 1С

Базовый образ Ubuntu 22.04 LTS с установленными системными библиотеками шрифтов, фреймбуфером Xvfb и непривилегированным пользователем:

Dockerfile - Сборочный раннер 1СUTF-8Открыть файл
1 FROM ubuntu:22.04
2  
3 ENV DEBIAN_FRONTEND=noninteractive
4 ENV LANG=ru_RU.UTF-8
5 ENV LANGUAGE=ru_RU:ru
6 ENV LC_ALL=ru_RU.UTF-8
7  
8 # Установка системных утилит, шрифтов и графических библиотек для headless-режима
9 RUN apt-get update && apt-get install -y --no-install-recommends \
10     locales ca-certificates curl file git procps \
11     xvfb xauth fontconfig dbus-x11 libwebkit2gtk-4.0-37 \
12     libgl1 libglx-mesa0 msttcorefonts \
13     && locale-gen ru_RU.UTF-8 \
14     && update-locale LANG=ru_RU.UTF-8 LC_ALL=ru_RU.UTF-8 \
15     && fc-cache -fv \
16     && rm -rf /var/lib/apt/lists/*
17  
18 # Создание непривилегированного пользователя runner
19 RUN groupadd -g 1001 runner \
20     && useradd -u 1001 -g runner -m -s /bin/bash runner \
21     && mkdir -p /opt/1cv8 /var/1c/db /var/1c/licenses \
22     && chown -R runner:runner /opt/1cv8 /var/1c/db /var/1c/licenses
23  
24 # Установка платформы из подготовленного deb-дистрибутива
25 ONBUILD COPY ./dist/*.deb /tmp/1c-dist/
26 ONBUILD RUN apt-get update && (dpkg -i /tmp/1c-dist/*.deb || apt-get install -fy) \
27     && rm -rf /tmp/1c-dist /var/lib/apt/lists/*
28  
29 USER runner
30 WORKDIR /home/runner
31 ENV DISPLAY=:99
32  
33 CMD ["/bin/bash"]

2. Скрипт сборки и синтаксического контроля (1c-ci-linux-build-v4.sh)

Промышленный скрипт автоматизации со всеми 5 рубежами защиты, безопасной очисткой файловых дескрипторов и Telegram-уведомлениями:

Bash - 1c-ci-linux-build-v4.shUTF-8Открыть файл
1 #!/usr/bin/env bash
2 set - euo pipefail
3  
4 PATH_1C="/opt/1cv8/x86_64/current/1cv8"
5 DB_CONNECTION=""; DB_USER="Admin"; DB_PASS=""; EXT_NAME=""
6 TIMEOUT_LIMIT=300; SRC_DIR=""
7 RUN_ID=$(date +%Y%m%d_%H%M%S)_$RANDOM
8 LOG_FILE="/tmp/1c_log_${RUN_ID}.txt"; ERR_FILE="/tmp/1c_err_${RUN_ID}.txt"
9 ERR_PATTERN="ошибка|неопознан|ожидается|не определен|несоответств|не найден|неверн|error|expected|undefined|mismatch|not found|invalid|failed"
10  
11 cleanup() { rm -f "$LOG_FILE" "$ERR_FILE" /tmp/diff_result_${RUN_ID}.txt; }
12 trap cleanup EXIT
13  
14 # Зачистка зависших блокировок .1cLck
15 if [[ "$DB_CONNECTION" =~ ^/[Ff]"?([^"]+) ]] && ! pgrep -f "1cv8" >/dev/null; then
16     rm -f "${BASH_REMATCH[1]}"/*.1cLck "${BASH_REMATCH[1]}"/1Cv8.lk 2>/dev/null || true
17 fi
18  
19 CMD_ARGS="DESIGNER $DB_CONNECTION /N \"$DB_USER\" /P \"$DB_PASS\" /CheckModules -Server -ThinClient -WebClient /Out \"$LOG_FILE\" -NoTruncate"
20 [[ -n "$EXT_NAME" ]] && CMD_ARGS="$CMD_ARGS -Extension \"$EXT_NAME\""
21  
22 set +e
23 timeout --preserve-status "$TIMEOUT_LIMIT" "$PATH_1C" $CMD_ARGS 2> "$ERR_FILE"
24 STATUS=$?; set -e
25 [[ $STATUS -ne 0 ]] && { echo "[-] Сбой платформы ($STATUS)"; exit "$STATUS"; }
26  
27 # Слой 2: Проверка размера лога
28 [[ ! -s "$LOG_FILE" ]] && { echo "[-] Лог пуст. Падение Конфигуратора."; exit 100; }
29  
30 # Слой 1: Нормализация кодировки и удаление BOM
31 MIME=$(file -b --mime-encoding "$LOG_FILE")
32 [[ "$MIME" != "utf-8" && "$MIME" != "us-ascii" ]] && iconv -f "$MIME" -t UTF-8 "$LOG_FILE" -o "${LOG_FILE}.tmp" && mv -f "${LOG_FILE}.tmp" "$LOG_FILE"
33 sed -i '1s/^\xEF\xBB\xBF//' "$LOG_FILE"
34  
35 # Слой 3: Поиск ошибок синтаксиса
36 if grep - Eiq "$ERR_PATTERN" "$LOG_FILE"; then
37     echo "[-] Ошибки синтаксиса в модулях!"; exit 1
38 fi
39  
40 # Слой 5: Diff-контроль метаданных с Git
41 if [[ -n "$SRC_DIR" && -d "$SRC_DIR" ]]; then
42     TMP_DUMP="/tmp/dump_${RUN_ID}"; mkdir -p "$TMP_DUMP"
43     "$PATH_1C" DESIGNER $DB_CONNECTION /N "$DB_USER" /P "$DB_PASS" /DumpConfigToFiles "$TMP_DUMP" -Extension "$EXT_NAME" >/dev/null
44     diff -r --strip-trailing-cr -x "ConfigDumpInfo.xml" -x "*.orig" "$SRC_DIR" "$TMP_DUMP" > /tmp/diff_result_${RUN_ID}.txt || { echo "[-] Diff Error!"; exit 2; }
45     rm -rf "$TMP_DUMP"
46 fi
47  
48 echo "[+] Сборка успешно завершена."
49 exit 0

3. Оптимизированный logcfg.xml для продуктивной среды

Файл технологического журнала, настроенный на отслеживание тяжелых контекстных вызовов памяти, взаимных блокировок и формирования минидампов:

XML - logcfg.xmlUTF-8Открыть файл
1 <?xml version="1.0" encoding="UTF-8"?>
2 <config xmlns="http://v8.1c.ru/v8/tech-log">
3     <dump create="true" location="/var/1c/dumps" type="3" prntscr="false"/>
4     <log location="/var/log/1c_tech_log" history="48">
5         <event><eq property="Name" value="CALL"/><gt property="Memory" value="104857600"/></event>
6         <event><eq property="Name" value="SCALL"/><gt property="Memory" value="104857600"/></event>
7         <event><eq property="Name" value="DBPOSTGRS"/><gt property="Memory" value="52428800"/></event>
8         <event><eq property="Name" value="DBPOSTGRS"/><gt property="Duration" value="5000000"/></event>
9         <event><eq property="Name" value="TLOCK"/><gt property="WaitConnections" value="0"/></event>
10         <event><eq property="Name" value="TDEADLOCK"/></event>
11         <event><eq property="Name" value="EXCP"/></event>
12         <properties>
13             <property name="p:processName"/><property name="t:connectID"/><property name="SessionID"/>
14             <property name="Usr"/><property name="Memory"/><property name="MemoryPeak"/><property name="Duration"/>
15             <property name="Context"/><property name="Sql"/><property name="WaitConnections"/><property name="Exception"/><property name="Descr"/>
16         </properties>
17     </log>
18 </config>

9. План перехода на промышленный DevOps за 4 недели

  • Неделя 1: Развертывание локальной фабрики сборки
    Стандартизация Git-репозитория и выгрузки исходников EDT. Развертывание сборочного скрипта 1c-ci-linux-build-v4.sh на тестовом раннере.
    Критерий готовности: Сборка и синтаксический контроль расширения исполняются автоматически по коммиту без ручного вмешательства.
  • Неделя 2: Стандартизация Docker-окружения и сетевого лицензирования
    Сборка базового Docker-образа сборочного агента. Настройка выделенного сервера лицензий HASP (порт UDP 475) или организация монтирования каталога /var/1C/licenses в режиме --net=host.
    Критерий готовности: Пайплайны сборки изолированы в контейнерах, лицензирование стабильно работает при параллельных сборках.
  • Неделя 3: Профилирование памяти и запуск мониторинга
    Развертывание промышленного logcfg.xml на серверах баз данных. Настройка алертов в Prometheus на пороги потребления памяти 80% (Warning) и 95% (Critical). Включение ротации рабочих процессов в КОРП (--memory-excess-time 300) или подключение admincluster-monitor для лицензий ПРОФ.
    Критерий готовности: Память рабочих процессов стабилизирована, устранены ночные утечки в сессиях сервисов.
  • Неделя 4: Нагрузочное тестирование устойчивости (Chaos Engineering)
    Имитация аварий: аварийное завершение процессов через kill - 9 (проверка очистки брошенных .1cLck), симуляция синтаксических ошибок в условиях многопоточной сборки. Настройка сценариев автоматического восстановления контейнеров при критических сбоях.
    Критерий готовности: Автоматическое восстановление доступности кластера после сбоя менее чем за 2 минуты без участия дежурного инженера.

Переход на промышленный конвейер снимает с команды груз рутинных инцидентов: процесс сборки становится строго детерминированным, а жизненный цикл и память процессов сервера 1С берутся под полный инженерный контроль с помощью прозрачных системных инструментов Linux. Представленные конфигурации и скрипты образуют production-ready фундамент для внедрения зрелого DevOps в enterprise-инфраструктуре.

Проверено на следующих конфигурациях и релизах:

  • Управление торговлей, редакция 11, релизы 11.5.27.81

Вступайте в нашу телеграмм-группу Инфостарт

1С Linux DevOps CI/CD кластер 1С rphost rmngr доступность отказоустойчивость мониторинг профилирование памяти утечки памяти Docker HASP nethasp.ini systemd logcfg.xml RAS API автоматизация self-healing

+1 –

См. также

Оптимизация запросов с оператором «В» для составных типов в 1С и СУБД Postgres

HighLoad оптимизация Программист 1С 8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Использование оператора «В» для полей или данных составного типа (например, Регистратор) может приводить к неочевидным проблемам.

10.11.2025    14378    ivanov660    48    

57
Проблемы производительности. Оператор различные в динамических списках

HighLoad оптимизация Программист 1С:Предприятие 8 1C:ERP Бесплатно (free)

Приведем примеры использования различных в динамических списках и посмотрим, почему это плохо.

18.02.2025    15306    ivanov660    39    

62
Проблемы производительности. Индексация с дополнительным упорядочиванием

HighLoad оптимизация Системный администратор Программист 1C:ERP Бесплатно (free)

Не всегда индексирование с дополнительным упорядочиванием полезно.

04.02.2025    13873    ivanov660    21    

58
Как сервер 1С меняет параметры у PostgreSQL

HighLoad оптимизация Программист Россия Бесплатно (free)

А вы знали, что сервер 1С при соединении с базой на сервере PostgreSQL самостоятельно устанавливает некоторые параметры? Это важно знать при настройке сервера и отладке долгих запросов. Предлагаю разобраться.

27.08.2024    9274    soulner    10    

41
Длительные вызовы - CALL, SCALL

HighLoad оптимизация Технологический журнал Системный администратор Программист Бесплатно (free)

Обсудим поиск и разбор причин длительных серверных вызовов CALL, SCALL.

24.06.2024    17836    ivanov660    13    

64
Что не так с методом ЗаполнитьЗначенияСвойств

HighLoad оптимизация Программист 1С:Предприятие 8 Бесплатно (free)

Метод очень медленно работает, когда параметр приемник содержит намного меньше свойств, чем источник.

06.06.2024    23837    Evg-Lylyk    73    

46
[Замер] Кто самый быстрый в конфигураторе?

HighLoad оптимизация Механизмы платформы 1С Системный администратор Программист Стажер 1С:Предприятие 8 Бесплатно (free)

Сравним «Регистры сведений» с «Сервисами интеграции» и узнаем, кто быстрее!

28.03.2024    13672    dsdred    27    

43
Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы

HighLoad оптимизация Программист 1С:Предприятие 8 1C:Бухгалтерия Бесплатно (free)

Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.

13.03.2024    13625    spyke    29    

54
Для отправки сообщения требуется регистрация/авторизация