В этой публикации мы подробно разберем комплексный реальный кейс обновления сервера 1С:Предприятие на базе Linux, который изначально планировался как рядовой апдейт для решения проблемы с чтением кодов маркировки, но вылился в масштабную ревизию архитектуры и СУБД.
1. Проблема с GS1 DataMatrix
С внедрением системы «Честный ЗНАК» многие предприятия столкнулись с невозможностью корректного сканирования кодов. В релизе платформы 8.3.16.1224 и ниже присутствует известная ошибка: внутренние механизмы 1С некорректно обрабатывают скрытые служебные символы-разделители (такие как <GS> или FNC1). В итоге от сканера приходит искаженная строка, криптохвост теряется, и валидация марки завершается провалом. Переход на релиз 8.3.16.1814 и выше является обязательным шагом, поскольку в этой версии парсинг спецсимволов DataMatrix был полностью исправлен разработчиками.
2. Аудит сервера и обнаружение бутылочного горлышка
Исходные данные сервера (без доступа к iLO*):
- Операционная система: Ubuntu 16.04.
- Аппаратная часть: Intel Core i5-9600KF, 64 ГБ оперативной памяти.
- СУБД: PostgreSQL 10.11.
* Лирическое отступление: Что такое iLO и почему работать без него — это ходить по минному полю?
iLO (Integrated Lights-Out) — это встроенная технология аппаратного удаленного управления серверами (out-of-band management), разработанная компанией Hewlett Packard Enterprise (HPE). У других вендоров существуют свои аналоги: iDRAC у Dell, IMM у Lenovo или универсальный стандарт IPMI/BMC (Baseboard Management Controller) у Supermicro.
По сути, это независимый мини-компьютер, распаянный прямо на материнской плате сервера. Он имеет собственный сетевой порт, процессор и микро-ОС. iLO получает дежурное питание и начинает работать ровно в тот момент, когда шнур питания вставляется в розетку сервера, независимо от того, включен ли сам сервер.
Что позволяет делать iLO:
- Полное управление питанием: Вы можете удаленно включить, выключить или выполнить аппаратный сброс (нажать физическую кнопку Reset), даже если операционная система намертво зависла (OOM Killer, Kernel Panic).
- Виртуальная консоль (KVM KVM-over-IP): Вы видите вывод на экран монитора с самой первой секунды загрузки — можете зайти в BIOS/UEFI, управлять RAID-контроллером и видеть меню загрузчика GRUB.
- Виртуальные носители (Virtual Media): Позволяет удаленно «вставить» ISO-образ с вашего ноутбука в сервер, чтобы переустановить операционную систему с нуля.
Что это значило в контексте нашего апгрейда? В исходных данных было указано, что мы работаем без доступа к iLO. Это означало, что управление сервером осуществлялось исключительно внутри самой ОС Ubuntu через SSH. У администратора в такой ситуации нет права на фатальную ошибку.
Если бы в процессе обновления пакетов 1С мы случайно задели сетевые настройки, переполнили диск, или если бы после настройки PostgreSQL ядро Linux отказалось загружаться — доступ по SSH был бы безвозвратно потерян. Без аппаратной консоли iLO вернуть такой сервер к жизни можно только одним способом: физически ехать в дата-центр (офис заказчика) с монитором и клавиатурой под мышкой. Именно поэтому все шаги по миграции, очистке процессов и настройке СУБД выверялись с двойной осторожностью.
Вернёмся обратно к нашему «бутылочному горлышку». Анализ запущенных служб выявил критическую недоработку предыдущих администраторов. Процессы сервера 1С (ragent, rmngr, rphost) запускались из директории /opt/1C/v8.3/i386/. Это означало, что на сервере с 64 ГБ ОЗУ функционировала 32-битная версия платформы. Такая архитектура — искусственное бутылочное горлышко. 32-битный процесс не может эффективно адресовать доступную память, что неизбежно ведет к падению производительности при формировании тяжелых отчетов. Было принято решение провести полную миграцию на 64-битную архитектуру.
3. Подготовка к архитектурному переходу
Установка пакетов x86_64 поверх i386 недопустима. Стратегия безопасной миграции включает:
- Резервное копирование директории кластера reg_1541. Крайне важно использовать команду cp с ключом -a для полного сохранения прав владельца usr1cv8.
- Штатную остановку службы srv1cv83 и обязательную проверку через ps aux отсутствия зависших процессов в памяти.
- Деинсталляцию старых 32-битных компонентов через менеджер пакетов ОС.
- Чистую установку новой архитектуры с автоматическим подхватом аппаратного HASP-ключа.
Далее мы рассмотрим техническую реализацию этого плана в консоли Linux, а также столкнемся с опасными настройками PostgreSQL, способными вызвать жесткое падение сервера из-за исчерпания памяти (OOM Killer).
Мы разобрали причины, по которым старые релизы платформы (в частности, 8.3.16.1224) не справляются с кодами маркировки GS1 DataMatrix, а также выявили серьезную архитектурную проблему нашего сервера — использование 32-битной платформы при наличии 64 ГБ оперативной памяти. Теперь переходим к практической реализации задуманного: консольной магии, обновлению пакетов и спасению СУБД.
4. Практика миграции: удаление i386 и установка x86_64
Работа в консоли Linux требует аккуратности, особенно когда речь идет о продуктовом сервере. Мы не можем просто накатить новые .deb пакеты поверх старых, так как меняется сама архитектура приложения.
Шаг 1. Безопасный бэкап кластера Первым делом необходимо сохранить настройки кластера серверов 1С и списки зарегистрированных баз. Файлы лежат в скрытой директории пользователя usr1cv8. Критически важно сохранить права доступа, поэтому используем флаг -a (archive):
sudo cp -a /home/usr1cv8/.1cv8 /tmp/1c_update/1cv8_backup
Визуально убедившись, что папка reg_1541 и файл 1cv8wsrv.lst на месте, а владельцем остался usr1cv8, можно двигаться дальше.
Шаг 2. Остановка служб и зачистка процессов Останавливаем службу сервера 1С:
sudo systemctl stop srv1cv83
И здесь кроется частая ловушка. Systemd может отчитаться об остановке службы, но процессы-зомби могут остаться висеть в памяти, блокируя файлы. Обязательно проверяем:
ps aux | grep ragent
Если вывод пустой (или показывает только сам процесс grep), всё отлично. Если же процессы ragent, rmngr или rphost остались, их нужно принудительно завершить через sudo killall.
Шаг 3. Деинсталляция 32-битной платформы Получаем точный список установленных пакетов 1С:
dpkg -l | grep 1c-enterprise
В выводе мы четко видим суффикс архитектуры :i386. Формируем команду на полное удаление:
sudo apt-get remove 1c-enterprise83-common:i386 1c-enterprise83-common-nls:i386 1c-enterprise83-crs:i386 1c-enterprise83-server:i386 1c-enterprise83-server-nls:i386 1c-enterprise83-ws:i386 1c-enterprise83-ws-nls:i386
Система может выдать предупреждение, что директория /opt/1C/v8.3/i386 не пуста и не была удалена (обычно там остаются технологические логи или временные файлы). Это штатная ситуация, которая нам не помешает, так как новая платформа ляжет в соседнюю папку x86_64.
Шаг 4. Развертывание 64-битной версии Переходим в директорию со скачанными пакетами релиза 8.3.16.1814 и запускаем установку:
sudo dpkg -i *.deb
После распаковки стартуем службу:
sudo systemctl start srv1cv83
Служба автоматически подхватывает конфигурацию из домашней директории пользователя usr1cv8, и кластер поднимается уже на 64-битных рельсах. Проверка через клиентскую часть показала, что аппаратный USB-ключ (HASP) корректно распознался новым процессом и успешно выдал лицензию.
5. Аудит PostgreSQL: бомба замедленного действия в файле postgresql.conf
Сервер 1С обновлен, но впереди нас ждал главный сюрприз. Открыв конфигурационный файл СУБД (/etc/postgresql/10/main/postgresql.conf), я решил проверить, как утилизируются доступные 64 ГБ оперативной памяти.
То, что я там увидел, заставило вздрогнуть:
- shared_buffers = 8192MB
- work_mem = 1280MB
- maintenance_work_mem = 2048MB
- effective_cache_size = 4096MB
Параметр work_mem был выставлен в астрономические 1280MB. Для тех, кто не глубоко погружен в тюнинг PostgreSQL, поясню: work_mem — это не общий объем памяти для СУБД. Это лимит памяти, который выделяется на каждую операцию сортировки или кэширования хэш-таблиц в рамках одного запроса. Сложный запрос с несколькими джоинами и сортировками может потребовать work_mem несколько раз.
Если в базе начнут активно работать пользователи и одновременно запустят формирование тяжелых отчетов (например, ОСВ по всем счетам с детализацией), PostgreSQL попытается выделить каждому процессу по несколько гигабайт памяти. На сервере с 64 ГБ ОЗУ это неминуемо приведет к исчерпанию физической памяти. Дальше в дело вступит системный OOM Killer (Out Of Memory) операционной системы Linux, который просто "убьет" самый прожорливый процесс. Этим процессом окажется служба PostgreSQL, и база рухнет в самый неподходящий момент.
Лечение конфигурации:
- Мы радикально срезали work_mem до безопасных и оптимальных 64MB. Этого более чем достаточно для подавляющего большинства транзакционных баз 1С.
- Параметр effective_cache_size (подсказка планировщику запросов об объеме системного файлового кэша) был увеличен с нелепых 4 ГБ до адекватных 24GB.
- Параметры shared_buffers (8GB) и maintenance_work_mem (2GB) были оставлены без изменений, так как они вполне соответствовали нашему железу.
После внесения правок мы перезапустили СУБД:
sudo systemctl restart postgresql
На этом серверная часть была полностью оптимизирована. База получила возможность дышать полной грудью, а угроза падения по памяти была ликвидирована.
Однако, на следующее утро заказчик сообщил о новой проблеме: перестали работать сканеры штрихкодов на рабочих местах. Развязку этой ситуации и финальные выводы мы рассмотрим далее.
Напомню, до этого мы успешно перевели серверную часть 1С на 64-битную архитектуру, чтобы утилизировать 64 ГБ оперативной памяти, и спасли PostgreSQL от верной гибели из-за неадекватных лимитов work_mem. Казалось бы, можно выдыхать и закрывать задачу, но на следующее утро прилетела классическая заявка от пользователей: «У нас ничего не работает, сканеры штрихкодов пикают, но в 1С ничего не появляется».
Давайте разберем эту ситуацию, которая является типичной ловушкой при обновлении инфраструктуры.
6. Конфликт поколений: когда x64 ломает старое железо
При подключении к клиентскому рабочему месту на экране красовалась служебная ошибка:
АТОЛ: Сканер штрихкода: Не удалось загрузить драйвер торгового оборудования. Необходимо проверить корректность установки драйвера.
Рядом пестрели аналогичные ошибки компоненты «1С:Печать штрихкодов».
Первая мысль админа в такой ситуации — «слетели драйверы» или «нужно перерегистрировать dll через regsvr32». Но если заглянуть в список установленных программ на этом компьютере (через Панель управления), всё становится на свои места:
- Установлены «Драйверы торгового оборудования v.6» от 13.11.2008.
- Установлен классический «Элемент управления 1С:Печать штрихкодов».
Это старые, добрые, проверенные временем 32-битные (x86) нативные COM-компоненты.
В чем же заключалась ошибка? В порыве перфекционизма после обновления сервера на x64, на клиентские машины под управлением Windows была установлена 64-битная версия тонкого/толстого клиента 1С (релиз 8.3.16.1814).
С точки зрения архитектуры операционных систем семейства Windows, 64-битный процесс приложения (1cv8.exe или 1cv8c.exe) физически не имеет возможности загрузить в свое адресное пространство 32-битную динамическую библиотеку (.dll). Система изолирует их друг от друга. Платформа 1С честно пытается обратиться к COM-объекту драйвера АТОЛ, получает отказ от ОС на уровне архитектуры и выдает сообщение «Не удалось загрузить драйвер».
Многие в этот момент начинают паниковать, искать 64-битные версии драйверов торгового оборудования (которые для старых сканеров часто просто не существуют в природе) или предлагать заказчику купить новые сканеры.
7. Элегантное решение без дополнительных затрат
Красота трехуровневой клиент-серверной архитектуры 1С:Предприятие заключается в том, что серверный кластер и клиентское приложение общаются по собственному сетевому протоколу. Разрядность сервера и клиента не обязана совпадать.
Чтобы вернуть к жизни сканеры и печать штрихкодов, достаточно было выполнить два простых шага:
- Полностью деинсталлировать 64-битную платформу 1С с рабочих мест кассиров и менеджеров.
- Скачать и установить 32-битную платформу клиента 1С того же релиза 8.3.16.1814.
Как только пользователи зашли в базу через 32-битный клиент, платформа без проблем подцепила старые COM-библиотеки АТОЛ 2008 года. Сканеры заработали мгновенно, без единой перенастройки портов, суффиксов или перерегистрации dll.
При этом наш мощный сервер на Ubuntu остался работать на 64-битной платформе, обрабатывая гигантские массивы данных и эффективно используя все 64 ГБ оперативной памяти.
8. Итоги и выводы проекта
То, что начиналось как локальная задача «обновить платформу, чтобы заработали коды маркировки DataMatrix», вылилось в полноценный аудит и рефакторинг инфраструктуры.
Подводя итоги, мы получили следующие результаты:
- Маркировка работает идеально. Релиз 8.3.16.1814 корректно перехватывает управляющие символы <GS>, криптохвосты сохраняются, валидация в «Честном ЗНАКе» проходит без ошибок.
- Сервер раскрыл свой потенциал. Переход процессов ragent, rmngr и rphost на архитектуру x86_64 позволил 1С использовать весь объем ОЗУ. Узкое горлышко 32-битной адресации ликвидировано.
- СУБД стабилизирована. Снижение параметра work_mem в PostgreSQL с безумных 1280MB до 64MB устранило риск падения сервера из-за исчерпания памяти при пиковых нагрузках, а увеличение effective_cache_size до 24GB ускорило чтение горячих данных.
- Бюджет заказчика сэкономлен. Благодаря использованию 32-битных клиентов на рабочих местах, мы сохранили совместимость с легаси-оборудованием. Покупать новые сканеры или фискальные регистраторы не пришлось.
Этот кейс — отличная иллюстрация того, что администратор или архитектор 1С должен смотреть на систему комплексно, от файлов конфигурации СУБД в консоли Linux до разрядности старых библиотек на рабочем месте кассира.
Надеюсь, эта статья поможет коллегам избежать подводных камней при миграциях и настройках серверов. Всем аптайма и быстрых запросов!
Бонус: Настройка технологического журнала в JSON и парсинг консольными утилитами
Апгрейд сервера и оптимизация СУБД — это фундамент, но после перехода на 64-битную платформу крайне важно наладить мониторинг потребления ресурсов (в частности, CPU и оперативной памяти) в разрезе отдельных пользовательских сессий. На серверах Ubuntu идеальным решением для этой задачи является настройка технологического журнала (ТЖ) платформы 1С с выводом логов в формате JSON.
Традиционный текстовый ТЖ неплох, но он тяжело поддается автоматизированному машинному парсингу. Вывод в JSON на Linux-системах — это совершенно другой уровень удобства. Для активации сбора логов в директории conf новой 64-битной платформы (/opt/1C/v8.3/x86_64/conf) необходимо создать или отредактировать файл logcfg.xml.
Особое внимание при профилировании тяжелых баз данных стоит уделить точности замеров времени исполнения событий. Часто администраторы ориентируются на стандартное свойство Duration. Однако для по-настоящему глубокой аналитики высоконагруженных систем и поиска микро-блокировок целесообразно оперировать значениями длительности в микросекундах. Для этого в логах следует анализировать параметр DurationUS. Именно он позволяет отлавливать те самые невидимые микро-задержки, которые в сумме создают у пользователей ощущение «тормозящей базы».
Сам факт сбора логов в структурированный JSON открывает отличные возможности для аналитики прямо в терминале сервера. Отпадает необходимость скачивать гигабайтные массивы сырых текстовых логов на рабочую станцию Windows, чтобы там долго скармливать их сторонним парсерам. Вместо этого в бой вступают нативные bash-утилиты Linux.
Например, используя связку популярных потоковых фильтров jq (для парсинга JSON) и awk (для обработки текста и математики), можно написать компактные аналитические bash-скрипты. С их помощью буквально одной строкой в консоли можно агрегировать объем потребленной памяти по конкретному номеру сеанса (SessionID) или мгновенно вывести топ-10 самых долгих фоновых заданий, опираясь на показатели DurationUS.
Такой подход позволяет диагностировать аномалии производительности и утечки памяти «на лету», не прерывая SSH-сессию и сохраняя полный контроль над сервером
Вступайте в нашу телеграмм-группу Инфостарт