Каждый администратор крупных информационных баз 1С рано или поздно сталкивается с ситуацией «необъяснимого» зависания системы. Сценарий выглядит классически: в разгар рабочего дня у произвольного пользователя белеет экран, курсор превращается в синий вращающийся кружок ожидания, а следом по цепочке (каскадно) начинают зависать абсолютно все остальные активные сеансы. При этом мониторинг СУБД (например, MS SQL Server) не показывает явных взаимоблокировок, нагрузка на процессоры серверов остается в пределах нормы, а попытка принудительно завершить «подвисшие» сеансы через консоль администрирования кластера 1С приводит к длительному ожиданию и ошибкам связи с сервисами кластера.
В этой статье мы подробно проанализируем причины возникновения данной проблемы, разберем архитектурные особенности взаимодействия платформы 1С с операционной системой и СУБД, а также рассмотрим по шагам надежные методы диагностики и гарантированного устранения подобных каскадных зависаний.
Для начала давайте детально изучим картину сбоя, чтобы вы могли безошибочно идентифицировать аналогичную проблему в своей системе:
Ошибка удаления сеанса: Ошибка операции администрирования. Не найдено ни одного сервера с размещенным сервисом serviceName=SessionDataService.rphost постоянно перезапускается. У него каждую минуту меняется идентификатор процесса (PID). Это говорит о том, что процесс падает в аварийный дамп или принудительно завершается менеджером кластера по таймауту.Главным виновником описанного поведения системы является новый формат журнала регистрации (ЖР), который был представлен фирмой «1С» в платформе версии 8.3.5. В этом формате данные ЖР хранятся не в текстовых файлах, а в базе данных SQLite (файл с расширением *.lgd).
Проанализируем, почему это приводит к катастрофическим зависаниям на нагруженных базах с числом активных пользователей более 30–50 человек:
Природа SQLite. СУБД SQLite является встраиваемой (embedded) однопользовательской базой данных. В отличие от полноценных клиент-серверных СУБД, SQLite не имеет собственного запущенного процесса-сервера, который управляет распределением ресурсов. Все операции чтения и записи выполняются непосредственно библиотекой, встроенной в рабочий процесс 1С rphost, напрямую на уровне файловой системы операционной системы.
Файловые блокировки при транзакциях. Когда пользователь в 1С проводит документ, платформа открывает транзакцию СУБД и одновременно пытается записать событие начала транзакции в журнал регистрации. Чтобы гарантировать целостность данных в файле *.lgd, библиотека SQLite накладывает монопольную блокировку на уровне операционной системы на весь файл базы данных ЖР. В этот момент никакой другой процесс rphost или поток не может выполнить запись в этот файл.
Эффект «бутылочного горлышка». Если в системе работает много пользователей, они генерируют сотни событий в секунду. Как только один из потоков захватывает блокировку файла ЖР на медленном диске или при задержках в виртуальной сети, выстраивается огромная очередь из других потоков rphost, ожидающих освобождения файла *.lgd. С точки зрения пользователя это выглядит как «белый экран» ожидания.
Падение rphost и ошибка SessionDataService. Менеджер кластера 1С (процесс rmngr) регулярно опрашивает рабочие процессы rphost (так называемый пинг или heartbeat-запрос). Если рабочий процесс намертво завис в ожидании снятия файловой блокировки с файла SQLite, он перестает отвечать менеджеру кластера. Менеджер кластера считает этот rphost аварийно завершенным и пытается перенаправить сеансы на новый запущенный рабочий процесс. Именно в этот переходный момент администратор получает ошибку о недоступности сервиса данных сеанса SessionDataService.
Прежде чем вносить изменения в рабочую систему, мы должны подтвердить гипотезу об аварийном завершении процессов и проблемах с блокировками. Для этого настроим сбор логов технологического журнала (ТЖ) 1С.
Создадим или отредактируем файл конфигурации технологического журнала logcfg.xml, который должен располагаться в каталоге установки платформы (например, для Windows: C:\Program Files\1cv8\conf\logcfg.xml).
Рассмотрим оптимальный шаблон конфигурационного файла, разработанный специально для отслеживания исключительных ситуаций (EXCP), падений процессов в дамп и таймаутов блокировок:
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<dump create="true" location="C:\1C_LOGS\Dumps" type="0" prntscrn="false" externaldump="1"/>
<log location="C:\1C_LOGS\AllExceptions" history="168">
<event>
<eq property="Name" value="EXCP"/>
</event>
<event>
<eq property="Name" value="CONN"/>
</event>
<event>
<eq property="Name" value="PROC"/>
</event>
<event>
<eq property="Name" value="ADMIN"/>
</event>
<event>
<eq property="Name" value="SESN"/>
</event>
<event>
<eq property="Name" value="CLSTR"/>
</event>
<property name="all"/>
<property name="context">
<event>
<ne property="process" value="rmngr"/>
</event>
</property>
</log>
<log location="C:\1C_LOGS\LockErrors" history="168">
<event>
<eq property="name" value="TLOCK"/>
<gt property="duration" value="100000"/>
</event>
<event>
<eq property="Name" value="TTIMEOUT"/>
</event>
<event>
<eq property="Name" value="TDEADLOCK"/>
</event>
<property name="all"/>
<property name="context">
<event>
<eq property="name" value=""/>
</event>
</property>
</log>
</config>
Разберем ключевые параметры данной настройки:
<dump create="true" ...> указывает платформе автоматически создавать дампы памяти при критических сбоях процессов rphost. Это бесценный источник информации для расследования причин падения серверов.EXCP фиксирует все исключительные ситуации, включая ошибки СУБД, критические сбои ядра платформы и аварийные дампы.history="168" ограничивает время хранения собранных логов до 7 суток (168 часов), что предотвращает переполнение дискового пространства сервера логами.TLOCK, TTIMEOUT и TDEADLOCK отслеживают транзакционные блокировки на уровне платформы 1С и СУБД, которые длятся более 0.1 секунды (100 000 микросекунд).После активации ТЖ проанализируем файлы логов в каталоге C:\1C_LOGS\AllExceptions. Если мы увидим регулярные события EXCP, связанные с записью в файлы в каталоге 1Cv8JobReg (где хранятся данные журнала регистрации), и последующие запуски новых процессов с событием PROC, наша гипотеза о блокировках SQLite полностью подтверждается.
Если диагностика подтвердила проблему, единственным надежным, стабильным и официально рекомендованным архитектурным решением является возврат журнала регистрации к старому, проверенному временем последовательному формату (текстовые файлы с расширением *.lgf).
В этом формате записи просто дописываются в конец текстового файла без использования сложных транзакционных механизмов баз данных и блокировок всей таблицы. Это снимает проблему конкурентной записи сотен пользователей.
Инструкция по изменению формата журнала регистрации:
"C:\Program Files\1cv8\8.3.10.2580\bin\1cv8.exe" DESIGNER /S "ИмяСервера\ИмяБазы" /N "Администратор" /P "Пароль" /ConvertRegLog старый
1Cv8.lgd обратно в текстовый структурированный набор файлов 1Cv8.lgf.
C:\Program Files\1cv8\srvinfo\reg_1541\UUID_вашей_базы\1Cv8Log) и убедитесь, что в каталоге появились файлы с расширением *.lgf, а размер файла 1Cv8.lgd перестал расти. Старый файл *.lgd после успешной конвертации можно безопасно удалить для освобождения дискового пространства.Помимо изменения формата ЖР, на стабильность транзакций существенно влияет сетевая инфраструктура, особенно если пользователи и серверы разнесены по разным виртуальным подсетям (VLAN). Выполним несколько важных настроек для минимизации сетевых задержек:
Оптимизация работы с ключами защиты HASP. При микроразрывах сети клиентское приложение может потерять связь с менеджером лицензий HASP. В этот момент клиент замирает, опрашивая всю сеть широковещательными запросами, что сервер воспринимает как зависшую транзакцию. Избавимся от этого, жестко прописав адрес сервера лицензирования в файле настроек nethasp.ini на компьютерах пользователей:
[NH_COMMON]
NH_TCPIP = Enabled
[NH_TCPIP]
NH_SERVER_ADDR = 192.168.1.100 ; Укажите точный IP-адрес вашего сервера лицензирования
NH_PORT_NUMBER = 475
NH_TCPIP_METHOD = TCP
NH_USE_BROADCAST = Disabled
Настройка параметров виртуальных сетевых адаптеров. Если сервер 1С развернут в среде виртуализации (например, VMware vSphere или Hyper-V), убедитесь, что тип виртуального сетевого адаптера установлен как VMXNET3 (для VMware). В настройках сетевой карты на уровне операционной системы Windows Server отключите функции энергосбережения и параметры выгрузки контрольной суммы (IPv4 Checksum Offload, Large Send Offload), так как они могут приводить к непредсказуемым микрозадержкам пакетов при передаче больших объемов данных между сервером 1С и СУБД.
Мы детально разобрали скрытые механизмы работы платформы 1С при каскадных зависаниях. Как показывает реальная практика эксплуатации высоконагруженных систем, отказ от формата журнала регистрации SQLite (*.lgd) в пользу классического формата текстовых логов (*.lgf) полностью решает проблему каскадного накопления транзакционных ожиданий.
Более того, сама фирма «1С» официально признала формат SQLite неудачным архитектурным решением для СУБД общего назначения на сервере приложений: начиная с версии платформы 8.3.22, поддержка формата SQLite была полностью удалена из платформы, а системы принудительно возвращены на классический текстовый последовательный формат ЖР.
Выполнив шаги по конвертации журнала регистрации и точечно настроив технологический журнал для контроля стабильности рабочих процессов rphost, вы гарантированно защитите свою информационную базу от внезапных зависаний транзакций и обеспечите комфортную, бесперебойную работу пользователей.