← На главную

Каждый системный администратор и разработчик 1С рано или поздно сталкивается с нестандартными проблемами производительности систем. Представим ситуацию: в определенный момент в нескольких базах одновременно начинают лавинообразно расти блокировки. Пользователи жалуются на невозможность проведения документов, причем под одним пользователем документ проводится, а под другим — зависает. Перезапуск службы сервера 1С временно решает проблему, но через некоторое время всё повторяется. Самое странное — консоль администрирования 1С и СУБД MS SQL показывают полное отсутствие классических транзакционных блокировок таблиц. При этом в журнале регистрации номера транзакций «застывают» на одном месте или вовсе отображаются пустыми.

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

Выясняем причину: почему блокировки есть в 1С, но их нет в SQL?

Для начала разберем архитектуру работы платформы 1С:Предприятие. Запись любого важного события (проведение документа, изменение справочника, вход пользователя) сопровождается фиксацией этого действия в журнале регистрации. В старом формате (который используется по умолчанию во многих базах и имеет расширение .lgp) ЖР представляет собой набор текстовых и бинарных файлов на диске сервера приложений.

Запись в ЖР происходит синхронно непосредственно внутри транзакции СУБД. Процесс выглядит следующим образом:

1. Бизнес-логика платформы 1С открывает транзакцию в СУБД.
2. Выполняются необходимые изменения данных в таблицах SQL.
3. Рабочий процесс сервера 1С (rphost.exe) пытается записать событие транзакции в индексный файл лога 1Cv8.lgf или текущий файл .lgp.
4. После успешной записи файла ЖР транзакция фиксируется в СУБД (Commit).

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

Скрытые виновники: антивирусы, повреждение индексов и очереди дисков

Рассмотрим подробнее факторы, которые провоцируют появление этой проблемы:

1. Блокировка файлов антивирусным ПО. Это самая частая причина внезапного сбоя. После очередного обновления базы сигнатур или самого антивируса на сервере, защитник начинает сканировать динамически изменяемые файлы 1Cv8.lgf и *.lgp. Захватив файл монопольно на доли секунды, антивирус парализует работу рабочего процесса rphost.exe.
2. Повреждение индексного файла журнала регистрации. Файл 1Cv8.lgf содержит индексную структуру логов. При аварийном завершении работы сервера или нехватке места на диске этот файл может повредиться. Любая последующая попытка записи приводит к зацикливанию и зависанию потока.
3. Каскадный эффект единого процесса rphost. Если несколько информационных баз обслуживаются одним рабочим процессом rphost.exe, зависание потока ЖР в одной базе мгновенно парализует транзакции во всех остальных базах этого процесса.
4. Высокая очередь к дисковой подсистеме. Медленные жесткие диски (HDD) при пиковой нагрузке не справляются со скоростью записи логов. Очередь к диску растет, время отклика увеличивается, что приводит к таймаутам управляемых блокировок 1С.

Шаг 1. Локализация и диагностика проблемного процесса rphost

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

1. Перейдем в ветку «Рабочие процессы» нашего кластера.
2. Обратим внимание на колонку «Время отклика». Если этот показатель для какого-то процесса превышает 0.5 секунды, это явный признак зависания.
3. Определим идентификатор процесса (PID) проблемного rphost.exe.
4. Запустим диспетчер задач на сервере, найдем процесс с этим PID и завершим его принудительно. Это позволит восстановить работу пользователей на других процессах без перезагрузки всей ОС.

Шаг 2. Настройка исключений антивируса

Чтобы предотвратить повторение проблемы, в обязательном порядке настроим политики безопасности установленного на сервере антивируса. Нам необходимо добавить в список исключений (проверок в реальном времени) следующие объекты:

• Исполняемые файлы платформы 1С: ragent.exe, rmngr.exe, rphost.exe.
• Каталог хранения временных файлов и профиля пользователя, под которым запускается служба 1С.
• Рабочий каталог сервера 1С (каталог srvinfo, обычно расположенный по пути C:\Program Files\1cv8\srvinfo\).
• Файлы масок журналов регистрации: *.lgf, *.lgp, *.lgd.

Шаг 3. Сброс и ротация журнала регистрации

Если индексный файл ЖР поврежден, его необходимо пересоздать. Рассмотрим пошаговый алгоритм очистки и архивирования логов:

1. Остановим службу сервера 1С:Предприятия. Для этого можно воспользоваться командной строкой, запущенной от имени администратора:

net stop "1C:Enterprise 8.2 Server Agent"

Или для версии 8.3:

net stop "1C:Enterprise 8.3 Server Agent"

2. Перейдем в каталог базы данных на сервере 1С: C:\Program Files\1cv8\srvinfo\reg_1541\<Идентификатор_Базы>\1Cv8Log\.
3. Переименуем или переместим старую папку 1Cv8Log в архивную директорию на другом диске.
4. Создадим новую пустую папку 1Cv8Log. Внутри нее создадим пустой текстовый файл и переименуем его в 1Cv8.lgf (убедитесь, что расширение файла изменилось с .txt на .lgf).
5. Запустим службу сервера 1С:

net start "1C:Enterprise 8.3 Server Agent"

6. Откроем информационную базу в режиме Конфигуратора. Перейдем в меню «Администрирование» — «Настройка журнала регистрации». Установим периодичность разделения журнала, например, «По дням» или «По неделям». Это предотвратит разрастание единого файла ЖР до критических размеров, облегчит резервное копирование и снизит нагрузку на дисковую подсистему.

Шаг 4. Изоляция баз по разным рабочим процессам

Чтобы сбой в ЖР одной базы не приводил к остановке работы других систем, настроим изоляцию баз в консоли кластера 1С. Для этого:

1. В консоли администрирования перейдем к свойствам локального кластера.
2. Настроим «Требования назначения функциональности». Для критически важных баз зададим отдельные рабочие серверы или ограничим количество баз на один процесс rphost.exe (параметр «Количество баз на один процесс» в настройках кластера).
3. Это гарантирует, что даже при полном зависании ЖР в одной из тестовых или вспомогательных баз, основная рабочая база продолжит функционировать в штатном режиме.

Шаг 5. Перенос каталога srvinfo на быстрый накопитель

Если анализ производительности показывает высокую очередь к диску, где установлена служба 1С, настоятельно рекомендуется перенести рабочий каталог сервера (параметр -d в параметрах запуска службы ragent) на производительный SSD-накопитель. Это кардинально ускорит операции чтения и записи логов, минимизируя вероятность образования очередей блокировок.

Применяя эти комплексные меры, мы надежно защитим сервер 1С от внезапных зависаний транзакций и обеспечим стабильную и бесперебойную работу всех пользователей.