Почему работа с журналом регистрации блокирует работу пользователей в 1С и как это исправить?

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

Выясняем причину: почему возникают блокировки?

Корень проблемы кроется в изменении формата хранения журнала регистрации. Начиная с версии 8.3.5, компания 1С представила новый формат — .lgd, который базируется на СУБД SQLite. В отличие от старого текстового формата .lgf, новый формат обещал более быстрый поиск и удобство работы с данными.

Однако на практике выяснилось, что SQLite при выполнении сложных запросов на чтение (когда мы накладываем фильтры за большой период или по конкретным данным) накладывает блокировку на уровне всего файла. Поскольку 1С записывает в ЖР практически каждое действие пользователя (вход, начало транзакции, изменение объекта), любая задержка записи из-за «читающего» запроса выстраивает огромную очередь. В итоге система «подвисает» для всех, кто пытается выполнить любое действие, требующее фиксации в журнале.

Решение 1: Возврат к старому формату журнала регистрации (.lgf)

Если ваша база данных активно растет, а стандартный журнал в формате .lgd вызывает постоянные сбои, самым надежным решением будет возврат к «классическому» текстовому формату. Рассмотрим, как это сделать правильно, чтобы не потерять данные и восстановить работоспособность системы.

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

1. Остановим сервер 1С:Предприятие. Это необходимо, чтобы освободить дескрипторы файлов журнала.
2. Перейдем в каталог информационной базы на сервере. Обычно он находится по пути ...\srvinfo\reg_<PortNo>\<GUID>.
3. Найдем в этой папке каталог 1Cv8Log. Это и есть место хранения нашего журнала.
4. Переименуем или переместим текущий файл 1Cv8.lgd в безопасное место. Это позволит сохранить историю событий для последующего анализа сторонними средствами, если это потребуется.
5. Создадим в папке 1Cv8Log пустой текстовый файл с именем 1Cv8.lgf. Наличие файла с таким расширением заставит платформу при запуске использовать старый формат записи логов.
6. Запустим сервер 1С. Теперь система начнет писать логи в текстовый формат, который гораздо менее чувствителен к блокировкам при чтении.

Решение 2: Использование встроенных механизмов конвертации (для версий 8.3.12 и выше)

Если вы используете современные релизы платформы (начиная с 8.3.12), разработчики предусмотрели более цивилизованный способ смены формата. Проанализируем, как выполнить конвертацию интерактивно:

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

• Конвертация огромного файла ЖР может занять длительное время.
• На время конвертации база может быть недоступна или работать крайне медленно.
• Рекомендуется сначала протестировать этот процесс на копии базы, чтобы оценить временные затраты.

Также существует параметр командной строки для запуска конвертации. Мы можем использовать исполняемый файл 1cv8.exe с параметром /ConvertLogItf. Это полезно для автоматизации процесса через скрипты:

"C:\Program Files\1cv8\8.3.xx.xxxx\bin\1cv8.exe" /ConvertLogItf <ПутьКФайлуЖурнала> /ToNewFormat

Или в обратную сторону:

"C:\Program Files\1cv8\8.3.xx.xxxx\bin\1cv8.exe" /ConvertLogItf <ПутьКФайлуЖурнала> /ToOldFormat

Решение 3: Правильная настройка «здоровья» журнала регистрации

Чтобы работа с журналом не приводила к катастрофам, разберем несколько правил гигиены ЖР, которые помогут избежать блокировок даже без смены формата:

1. Разделение файлов по периодам. В настройках ЖР (через Конфигуратор) установим период разделения файла (например, «День» или «Неделя»). Для формата .lgf это позволит системе создавать новые файлы, и обращение к архивным файлам не будет мешать записи в текущий.
2. Использование флага «Отобрать сразу». В толстом клиенте или Конфигураторе при настройке фильтра журнала обязательно используйте опцию Отобрать сразу. Это позволит системе не пытаться «подгружать» данные динамически, что часто и вызывает длительные транзакции в SQLite.
3. Регулярная очистка и архивация. Не позволяйте файлу ЖР раздуваться до десятков гигабайт. Разберем алгоритм: раз в месяц выгружаем старые записи в отдельный файл, а из рабочей базы их удаляем. Это критически важно для производительности.
4. Команда VACUUM для SQLite. Если вы остаетесь на формате .lgd, помните, что простое удаление записей из журнала внутри 1С не уменьшает размер файла на диске. Файл остается фрагментированным. Чтобы физически сжать его и обновить индексы, необходимо периодически (при остановленной базе) выполнять команду VACUUM через утилиты работы с базами SQLite.

Решение 4: Вынос журнала на отдельный физический диск

Зачастую проблема блокировок усугубляется «узким местом» в дисковой подсистеме. Когда и основная база данных SQL, и файлы журнала регистрации 1С соревнуются за очередь чтения/записи на одном диске, возникают задержки. Проанализируем возможность оптимизации через инфраструктуру:

Перенесем папку srvinfo (или конкретно папку с логами через символьные ссылки ОС) на отдельный высокоскоростной SSD/NVMe диск. Это позволит разделить потоки ввода-вывода. Запись в журнал перестанет ждать, пока СУБД завершит тяжелую операцию с таблицами данных, и наоборот.

Решение 5: Ограничение детализации логирования

Иногда мы сами провоцируем блокировки, записывая в журнал избыточную информацию. Посмотрим на настройки уровней регистрации событий. Для большинства систем достаточно регистрировать только ошибки, предупреждения и важные действия пользователей (изменение документов, удаление). Регистрация событий типа Транзакция завершена или Транзакция отменена создает колоссальный объем «шума», который увеличивает количество записей в секунду и повышает вероятность коллизий в файле .lgd.

Альтернативный подход: Внешние системы анализа логов

Для крупных, высоконагруженных систем (Highload) работа с журналом регистрации внутри 1С вообще не рекомендуется. Рассмотрим современный стек технологий для этих целей:

• ELK Stack (Elasticsearch, Logstash, Kibana): данные из 1С выгружаются во внешнюю базу, предназначенную специально для поиска по огромным массивам текста. Анализ логов в Kibana никак не влияет на работу пользователей в 1С.
• ClickHouse: сверхбыстрая аналитическая база данных, в которую можно транслировать события ЖР. Поиск по миллиардам записей здесь занимает доли секунды.

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