← На главную

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

Архитектура проблемы и механизм блокировок

Выясним причину, по которой чтение логов способно остановить работу сотен активных сеансов. В платформе 1С:Предприятие 8.3 существует два формата хранения журнала регистрации: классический текстовый формат (файлы с расширением .lgf и .lgp) и новый формат на базе СУБД SQLite (файл 1Cv8.lgd).

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

1. Когда администратор или аналитик открывает журнал регистрации и накладывает тяжелый отбор, процесс rmngr начинает считывать данные из монолитного файла 1Cv8.lgd и запрашивает блокировку SQLite.
2. Рабочие процессы rphost, выполняющие операции пользователей (проведение документов, запись элементов), обязаны синхронно фиксировать события в журнале регистрации.
3. Поскольку движок SQLite при выполнении объемных запросов на чтение или перестроении индексов блокирует файл целиком, процессы rphost не могут записать новые события и встают в очередь ожидания блокировки.
4. В результате блокируется работа всех пользователей базы данных: интерфейс «замораживается», а операции завершаются по таймауту.

Проблема не зависит от того, вынесен ли каталог кластера reg_1541 на отдельный быстрый SSD-диск. Вынос каталога оптимизирует дисковый ввод-вывод (I/O), но не устраняет архитектурное ограничение механизмов блокировки внутри самой СУБД SQLite при взаимодействии rmngr и rphost.

Решение 1. Перевод журнала регистрации на классический формат

Наиболее надежным и проверенным решением является возврат журнала регистрации к классическому формату с разделением данных по периодам (дням или неделям).

Разберем по шагам, как перевести журнал регистрации в классический формат:

1. Откроем конфигуратор необходимой базы данных с административными правами.
2. В верхнем меню выберем пункт Администрирование > Настройка журнала регистрации.
3. В появившемся окне изменим формат хранения с нового на классический.
4. Установим периодичность разделения файлов (для нагруженных систем рекомендуется выбирать Разбивать по дням).
5. Сохраним настройки. Начнется процесс конвертации данных, который может занять длительное время в зависимости от текущего размера файла 1Cv8.lgd.

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

Решение 2. Оптимизация уровня детализации событий

Если журнал регистрации растет до размеров в десятки и сотни gigabyte, необходимо проанализировать, какие именно данные в него записываются. Зачастую существенную долю объема занимают рутинные операции, не несущие высокой ценности для аудита.

Проанализируем варианты оптимизации состава записываемых событий:

1. В окне Настройка журнала регистрации снизим уровень детализации. Для большинства рабочих систем достаточно фиксировать категории Ошибка, Предупреждение и Информация.
2. Отключим фиксацию транзакционных событий и старта/завершения фоновых заданий, если они выполняются каждые несколько секунд.
3. Для высоконагруженных систем переведем режим журнала в значение Регистрировать только ошибки или временно отключим его для выполнения тяжелых технологических операций (например, при массовом перепроведении документов или загрузке данных).

Решение 3. Обслуживание и сжатие файла SQLite (если переход отложен)

В случаях, когда моментальный перевод на формат .lgf невозможно выполнить немедленно, требуется провести техническое обслуживание файла 1Cv8.lgd. Удаление старых записей средствами платформы не уменьшает физический размер файла на диске из-за особенностей работы SQLite.

Для освобождения дискового пространства и перестроения индексов выполним сжатие базы SQLite:

1. Остановим службу кластера серверов 1С:Предприятие (1C:Enterprise 8.3 Server Agent).
2. Убедимся, что процессы rmngr и rphost полностью завершили работу.
3. Запустим консольную утилиту sqlite3 и выполним команду упаковывания файла журнала: sqlite3 "C:\ProgramData\1C\1cv8\reg_1541\bb8e...\1Cv8.lgd" "VACUUM;"
4. Учтем, что для выполнения операции VACUUM на диске должно быть достаточно свободного места — не менее размера самого файла журнала.
5. Запустим службу кластера серверов.

При аварийном завершении процесса rmngr структура файла 1Cv8.lgd может повредиться (ошибка вида database disk image is malformed). В этом случае помогает выгрузка дампа базы с помощью команды .dump консоли sqlite3 и последующее воссоздание файла лога из полученного SQL-скрипта.

Альтернативные подходы к сбору логов

Посмотрим на рекомендации разработчиков платформы для крупного бизнеса. Начиная с версии платформы 8.3.22, поддержка формата SQLite (.lgd) была официально прекращена.

Для корпоративных систем высокой нагрузки рекомендуется использовать следующие архитектурные практики:

• Анализ вне рабочей базы: для расследования инцидентов скопируем файлы журнала на отдельный сервер или в тестовую среду и откроем их там, чтобы не нагружать менеджер кластера продуктивного контура.
• Внешние системы сбора логов: организуем сбор критичных событий через технологический журнал платформы и передадим их в специализированные внешние хранилища и системы анализа (например, ClickHouse или стек ELK).