← На главную

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

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

Причина блокировки: как SQLite парализует рабочий процесс rphost

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

Рассмотрим по шагам, что происходит при поиске в таком журнале:

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

Способ 1. Переход на последовательный (разделенный) формат журнала

Практика показала, что на крупных базах единый файл SQLite архитектурно не справляется с одновременным интенсивным чтением и записью. Самым надежным решением является перевод журнала регистрации в традиционный текстовый/последовательный формат (набор файлов .lgp, .lgx и 1Cv8.lgf). В этом формате запись новых событий происходит независимо от чтения архивов за прошлые дни, а файл журнала автоматически дробится по периодам (дням или неделям).

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

1. Остановим службу сервера 1С:Предприятия (через оснастку services.msc).
2. Перейдем в каталог служебных данных сервера: srvinfo\reg_XXXX\GUID_базы\1Cv8Log.
3. Создадим резервную копию каталога журнала регистрации (сохранив файл 1Cv8.lgd в безопасное место).
4. Выполним штатную утилиту конвертации из каталога установки платформы 1С:
   Скопировать код

   
   cd "C:\Program Files\1cv8\8.3.X.XXXX\bin"
   ibcmd infobase format-log-resize --ib-name=ИмяБазы --format=text
   

5. Либо удалим старый файл 1Cv8.lgd (при наличии архивной копии) и запустим службу сервера — платформа автоматически создаст новый журнал в последовательном формате, если это настроено по умолчанию для кластера.

Начиная с версии 8.3.12, последовательный формат снова стал основным и рекомендуемым фирмой «1С», а в релизах 8.3.22 и новее поддержка формата SQLite была полностью удалена из платформы.

Способ 2. Правила безопасного интерактивного просмотра

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

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

Способ 3. Оптимизация уровня логирования и дефрагментация

Проанализируем настройки самой конфигурации и дисковой подсистемы для снижения нагрузки:

1. Снижение уровня фиксации: В Конфигураторе откроем меню Администрирование → Настройка журнала регистрации. Если в системе включена полная запись всех событий, включая начало и завершение транзакций, размер журнала может расти на несколько гигабайт в день. Для высоконагруженных баз рекомендуется установить уровень «Регистрировать ошибки, предупреждения» либо выборочно исключить фоновые задачи.
2. Вынесение каталога журнала на скоростной SSD/NVMe: Папка srvinfo должна располагаться на быстрых твердотельных накопителях с высоким показателем IOPS.
3. Исключения антивируса: Обязательно добавим весь каталог служебных файлов сервера 1С (включая все подкаталоги 1Cv8Log) в список исключений антивирусного сканера реального времени. Сканирование дескрипторов файлов антивирусом при каждой записи многократно увеличивает время удержания файловой блокировки.
4. Физическое сжатие файла SQLite (VACUUM): Штатное сокращение журнала через меню Конфигуратора лишь помечает записи удаленными, но не уменьшает размер файла 1Cv8.lgd. Для физического освобождения пространства необходимо остановить службу 1С и выполнить утилиту: sqlite3.exe 1Cv8.lgd "VACUUM;"

Способ 4. Внедрение внешнего хранилища логов

Для крупных корпоративных внедрений с сотнями пользователей и жесткими требованиями к аудиту стандартный журнал регистрации 1С рекомендуется выгружать во внешние аналитические хранилища. Фоновый агент с заданной периодичностью считывает свежие порции логов и отправляет их во внешнюю базу данных (PostgreSQL, ClickHouse или Elasticsearch). Это позволяет выполнять сложные аналитические запросы и строить отчеты безопасности любой сложности без малейшего влияния на производительность продуктивной базы 1С.