Что делать, если при попытке открыть журнал регистрации зависает вся база 1С у всех пользователей?

Системный администратор 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

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

Выясняем причину: физика блокировок SQLite в формате .lgd

Начиная с версии платформы 8.3.5, разработчики 1С внедрили новый формат журнала регистрации — базу данных на СУБД SQLite (файлы с расширением .lgd). Предполагалось, что это ускорит выборки и повысит надежность хранения логов. Однако в высоконагруженных многопользовательских системах этот формат показал себя не с лучшей стороны.

Основная проблема кроется в архитектуре самой СУБД SQLite. По умолчанию она ориентирована на однопользовательскую работу или работу с преобладанием чтения. При попытке построить сложный отчет или применить тяжелый отбор в журнале регистрации (например, по метаданным, конкретному объекту или периоду) СУБД SQLite накладывает блокировку на чтение всего файла базы данных.

В этот же момент пользователи продолжают активно работать в 1С: проводить документы, записывать справочники, запускать фоновые задания. Любое из этих действий инициирует запись нового события в журнал регистрации. Но так как файл 1Cv8.lgd заблокирован процессом чтения, все транзакции записи выстраиваются в очередь ожидания. На сервере 1С лавинообразно растет число незавершенных вызовов, процессор уходит в 100% нагрузку на одном ядре, и база «зависает» абсолютно у всех.

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

Рассмотрим по шагам все возможные способы решения и оптимизации этой проблемы.

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

Это самый надежный, радикальный и рекомендованный способ. Текстовый формат не блокирует запись при чтении, а новые версии платформ оптимизированы для быстрой работы с ним за счет построения дополнительных индексов.

Выполним переход на старый формат по шагам:

  1. Запустим базу данных в режиме Конфигуратора с административными правами.
  2. В главном меню перейдем в раздел Администрирование — Настройка журнала регистрации.
  3. В открывшемся окне в поле «Формат журнала» выберем значение Последовательный (классический).
  4. Нажмем кнопку ОК. Платформа предложит выполнить конвертацию файла. Обратите внимание: на больших базах (более 2-3 Гб) процесс конвертации силами платформы может занять длительное время и также заблокировать работу.

Если автоматическая конвертация зависает или база слишком большая, можно поступить иначе:

  1. Полностью остановим службу сервера 1С:Предприятие.
  2. Перейдем в каталог на сервере, где хранятся файлы этой информационной базы (в папку srvinfo/reg_XXXX/XXXX-XXXX.../1Cv8Log).
  3. Переименуем или перенесем в архив старый файл 1Cv8.lgd.
  4. Запустим службу сервера 1С. Платформа автоматически создаст новый пустой файл журнала в текстовом формате 1Cv8.lgf.

Решение 2. Оптимизация и принудительное сжатие файла SQLite (VACUUM)

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

Простое удаление записей через стандартную обработку в Конфигураторе 1С («Сократить...») удаляет строки из таблиц, но не уменьшает физический размер файла на диске. СУБД SQLite просто помечает эти страницы как пустые. Чтобы вернуть дисковое пространство операционной системе, нужно запустить процедуру VACUUM.

Разберем процедуру дефрагментации файла лога:

  1. Полностью остановим службу сервера 1С:Предприятие, чтобы снять все блокировки с файла 1Cv8.lgd.
  2. Скачаем официальную консольную утилиту sqlite3.exe с официального сайта СУБД SQLite.
  3. Поместим утилиту в папку с журналом регистрации вашей базы данных.
  4. Откроем командную строку (cmd) от имени администратора, перейдем в каталог с журналом и выполним команду:

sqlite3.exe 1Cv8.lgd "VACUUM;"

Процесс может занять некоторое время в зависимости от исходного размера файла и скорости дисковой подсистемы. После завершения размер файла 1Cv8.lgd на диске существенно уменьшится.

Решение 3. Активация режима WAL (Write-Ahead Logging) для SQLite

Малоизвестный, но крайне эффективный системный лайфхак для предотвращения взаимных блокировок в формате .lgd — это перевод базы данных журнала регистрации в режим логирования транзакций WAL. В этом режиме операции чтения не блокируют операции записи, и наоборот.

Чтобы активировать этот режим, выполним следующие действия:

  1. Остановим службу сервера 1С.
  2. В командной строке в каталоге с файлом 1Cv8.lgd выполним команду с помощью утилиты sqlite3.exe:

sqlite3.exe 1Cv8.lgd "PRAGMA journal_mode=WAL;"

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

Решение 4. Сокращение объема регистрируемой информации

Часто журнал регистрации разрастается до огромных размеров из-за избыточного логирования. До 80% объема занимают записи транзакций фоновых и регламентных заданий (события начала, коммита и отката транзакций). Если эти данные вам не требуются для регулярного аудита, их фиксацию можно отключить.

Проанализируем настройки логирования в Конфигураторе:

  1. Перейдем в Администрирование — Настройка журнала регистрации.
  2. Изменим уровень детализации. Вместо «Регистрировать все события» установим выборочную регистрацию, например, исключив транзакции, или оставим логирование только ошибок и предупреждений (для баз с очень высокой транзакционной нагрузкой).

Если вам все же необходимо анализировать журнал регистрации, но делать это безопасно для пользователей, придерживайтесь следующих правил:

← На главную