Мы часто сталкиваемся с ситуацией, когда файл журнала регистрации 1С:Предприятия, особенно в клиент-серверном варианте работы, начинает неконтролируемо расти. Это может привести к быстрому заполнению дискового пространства, снижению производительности системы и усложнению диагностики проблем. Давайте разберем, почему это происходит и что мы можем предпринять для решения этой задачи.
Журнал регистрации (ЖР) в 1С:Предприятии — это системный механизм, предназначенный для записи информации о событиях, происходящих в информационной базе. К таким событиям относятся действия пользователей, выполнение регламентных заданий, ошибки, предупреждения, изменения данных и многое другое. Он критически важен для анализа работы системы, выявления проблемных мест, контроля доступа и отладки.
Журнал регистрации не хранится внутри самой информационной базы (ИБ). Он располагается в отдельной папке на сервере 1С:Предприятия или на компьютере пользователя (для файлового варианта). При операциях выгрузки/загрузки ИБ (например, в файл .dt) журнал регистрации не сохраняется. Мы всегда можем найти его по пути, аналогичному c:\Program Files\1cv8\srvinfo\reg_1541\GUID базы\1Cv8Log\, где GUID базы — это уникальный идентификатор вашей информационной базы.
Исторически в 1С:Предприятии существовали разные форматы хранения журнала регистрации, и понимание этих различий поможет нам в решении проблемы быстрого роста.
*.lgf): Этот формат использует текстовые файлы и фактически представляет собой набор файлов: основной файл 1Cv8.lgf, фрагменты журнала *.lgp и индексные файлы *.lgx. Его преимущество заключается в простоте работы с файлами и возможности разделения журнала по периодам (дням, неделям), что облегчает архивирование и удаление устаревших данных. Исторически этот формат зарекомендовал себя как достаточно надежный и производительный при правильной настройке.*.lgd): Начиная с платформы 1С:Предприятие версии 8.3.5, появился новый формат журнала регистрации, который представляет собой базу данных SQLite и имеет расширение *.lgd. Этот формат был введен с целью повышения скорости запросов к журналу и улучшения надежности хранения. Однако, как показала практика, при большом количестве пользователей и интенсивной работе, новый формат SQLite мог приводить к проблемам с производительностью, вплоть до зависания системы. Фирма 1С признала эти сложности.Важный нюанс: Обновление платформы до версии 8.3.5 и выше не приводит к автоматическому переключению уже существующих баз на новый формат. Однако, если мы создаем новую базу или пересоздаем старую с предварительной очисткой папки 1Cv8Log, то при отсутствии в ней файла 1Cv8.lgf будет создан журнал регистрации именно нового формата (*.lgd).
С версии 8.3.12 появилась возможность интерактивно выбирать формат журнала регистрации в настройках. А с версии 8.3.22 разработчики 1С и вовсе отказались от поддержки формата SQLite для журнала регистрации, исключив возможность конвертации в него. Таким образом, на текущий момент рекомендуется использовать старый (последовательный) формат.
Основная проблема формата *.lgd в контексте быстрого роста заключается в том, что даже после логического удаления устаревших записей через конфигуратор, физический размер файла на диске не уменьшается. Это особенность баз данных SQLite, которые резервируют место и не возвращают его операционной системе автоматически.
Прежде чем принимать меры, нам необходимо выяснить, что именно вызывает такой интенсивный рост журнала регистрации. Мы рассмотрим несколько шагов для диагностики.
Для начала, давайте убедимся, что уровень детализации записи событий в журнал настроен оптимально. Мы можем это сделать в конфигураторе: переходим в меню "Администрирование" > "Настройка журнала регистрации". Здесь мы увидим опции для выбора типа регистрируемых событий. Обычно нам достаточно регистрировать "Ошибки", "Предупреждения" и "Информацию". Отключение менее критичных событий (например, "Запуск", "Завершение", "Блокировка", "Изменение данных") может существенно сократить объем записываемой информации.
Также мы можем управлять детализацией программно, используя методы платформы: ПолучитьИспользованиеЖурналаРегистрации() и УстановитьИспользованиеЖурналаРегистрации() для общих настроек, а также ПолучитьИспользованиеСобытияЖурналаРегистрации() и УстановитьИспользованиеСобытияЖурналаРегистрации() для управления регистрацией конкретных типов событий.
Если журнал все равно быстро растет, нам нужно понять, какие именно события или действия приводят к этому. Мы можем открыть журнал регистрации через конфигуратор (меню "Администрирование" > "Журнал регистрации") или в режиме 1С:Предприятие (через "Все функции" > "Стандартные" > "Журнал регистрации" или "Администрирование" > "Обслуживание" > "Журнал регистрации"), а для детального анализа можно сделать выгрузку журнала в Excel.
В журнале мы увидим колонки с важной информацией: дата, время, пользователь, компьютер, приложение, событие, комментарий, сеанс. Фильтры помогут нам выявить "шумные" записи. Например, мы можем отфильтровать по типу события, по пользователю (возможно, есть один пользователь или регламентное задание, которое генерирует слишком много записей), по приложению или по комментарию, чтобы найти повторяющиеся или объемные записи.
Это очень важный пункт, часто являющийся основной причиной экстремально быстрого роста журнала регистрации. Как показывает опыт, включенный "Замер производительности", особенно в конфигурациях типа "Бухгалтерия Предприятия 3.0", может генерировать десятки гигабайт данных за считанные дни. Механизм замера производительности предназначен для детального анализа времени выполнения различных участков кода и выявления "узких мест" в работе системы. Однако, если он включен в рабочей базе без необходимости, он может стать источником серьезных проблем.
Мы должны проверить, активирован ли "Замер производительности". В типовых конфигурациях этот механизм может быть доступен через меню "Все функции" > "Стандартные" > "Настройки замеров производительности" или в разделе "Администрирование" > "Настройки пользователя" или "Общие настройки". Если мы обнаруживаем, что он включен, или видим опцию "Отображать показатели производительности", которую не используем, то нам следует немедленно ее отключить.
После проведения диагностики мы можем применить следующие методы для контроля размера и скорости роста файла журнала регистрации.
Этот метод часто оказывается самым эффективным, если диагностика показала, что именно "Замер производительности" является причиной проблемы. Этот механизм, собирая подробную информацию о каждом шаге выполнения кода, может быстро переполнить журнал.
В зависимости от конфигурации и версии платформы, путь к настройкам "Замера производительности" может немного отличаться. Обычно мы можем найти его через:
Если мы работаем с конфигурацией "Бухгалтерия Предприятия 3.0", то опция может быть расположена в общих настройках или настройках конкретных пользователей.
Найдя соответствующие настройки, мы должны снять флажок "Включен замер производительности" или аналогичную опцию. Также убедимся, что опция "Отображать показатели производительности" выключена, если она не используется.
После изменения настроек желательно перезапустить клиентское приложение 1С, а иногда и службу агента сервера 1С:Предприятия, чтобы изменения вступили в силу.
Учитывая выявленные проблемы с производительностью и управлением размером файла *.lgd, а также рекомендации самой фирмы 1С, возврат к старому текстовому формату *.lgf часто является наилучшим решением.
Это критически важный шаг. Журнал регистрации активно используется сервером 1С, поэтому для корректной работы с его файлами нам необходимо остановить все процессы, которые могут к нему обращаться. Для клиент-серверного варианта это означает остановку службы агента сервера 1С:Предприятия (обычно ее название начинается с "1C:Enterprise 8.3 Server Agent" или "Агент сервера 1С:Предприятия").
Мы должны найти папку, где хранится журнал регистрации для нашей информационной базы. Как мы уже упоминали, путь будет выглядеть примерно так: C:\Program Files\1cv8\srvinfo\reg_<PortNo>\<GUID базы>\1Cv8Log\. Здесь <PortNo> — это номер порта кластера серверов, а <GUID базы> — уникальный идентификатор вашей базы данных.
Внутри папки 1Cv8Log мы увидим файл 1Cv8.lgd (и, возможно, другие файлы, если ЖР работал в новом формате). Мы должны удалить все содержимое этой папки. Перед удалением обязательно сделайте резервную копию этих файлов! Мы можем просто переместить папку 1Cv8Log в другое место или переименовать ее, например, в 1Cv8Log_old.
1Cv8.lgf:
Это ключевой шаг для переключения на старый формат. В только что очищенной (или вновь созданной) папке 1Cv8Log мы создаем пустой текстовый файл и переименовываем его в 1Cv8.lgf. Наличие этого файла сигнализирует платформе 1С, что она должна использовать старый формат журнала регистрации.
Если на сервере у нас несколько информационных баз, и мы хотим применить это изменение ко всем, нам необходимо повторить шаги 2-4 для каждой из них.
После всех манипуляций мы запускаем службу агента сервера. Теперь 1С:Предприятие начнет записывать события в журнал регистрации в старом формате (*.lgf, *.lgp, *.lgx).
Независимо от используемого формата, правильная настройка журнала регистрации поможет нам контролировать его размер и собирать только необходимую информацию.
Мы уже упоминали об этом в разделе диагностики. В конфигураторе, в меню "Администрирование" > "Настройка журнала регистрации", мы должны выбрать только те типы событий, которые действительно нужны для анализа. Рекомендуем оставить "Ошибки", "Предупреждения", "Информация". Если у нас очень активная база, даже "Информация" может быть избыточной для ежедневного мониторинга, и ее можно отключить, если мы не ищем специфические информационные сообщения.
Пример: Если мы знаем, что регламентное задание "Обновление статусов заказов" работает каждую минуту и генерирует сотни записей типа "Информация", мы можем решить, что эти записи не несут критичной ценности для оперативного анализа, и отключить их.
*.lgf):
Это одна из ключевых настроек, которая становится доступной при использовании старого формата. В конфигураторе, в "Настройках журнала регистрации", мы можем установить опцию "Разделять хранение журнала регистрации по периодам". Мы можем выбрать интервал: по часам, дням, неделям, месяцам, годам. Например, установив "по дням", мы получим отдельные файлы журнала для каждого дня. Это значительно упрощает последующее архивирование и удаление старых частей журнала, поскольку нам не нужно вручную удалять записи внутри одного большого файла.
Мы должны выработать регламент регулярного сокращения журнала. В конфигураторе, в "Настройках журнала регистрации", есть кнопка "Сократить". Она позволяет удалить записи старше определенной даты. Мы можем настроить, например, удаление записей старше 7 дней.
Для старого формата *.lgf, при включенном разделении по периодам, мы можем просто настроить архивирование или перемещение старых файлов (например, недельной давности) в архивное хранилище или на более медленный диск. Это можно автоматизировать с помощью скриптов операционной системы.
Для нового формата *.lgd, после выполнения операции "Сократить", файл на диске не уменьшится. Для физического уменьшения нам потребуется выполнить команду VACUUM, о чем мы поговорим далее.
Если мы по каким-либо причинам вынуждены использовать новый формат *.lgd и столкнулись с проблемой его разрастания, то после логического удаления устаревших записей (через "Сократить" в конфигураторе) нам необходимо выполнить операцию VACUUM. Эта команда перестраивает базу данных SQLite, удаляя свободное место и фактически уменьшая размер файла на диске.
Как и в случае со сменой формата, для выполнения операции VACUUM мы должны убедиться, что ни один процесс не обращается к файлу 1Cv8.lgd. Для клиент-серверного варианта это означает остановку службы агента сервера 1С:Предприятия. Для файлового варианта работы достаточно убедиться в отсутствии активных сеансов с базой.
1Cv8.lgd:
Это обязательный шаг! Любые операции напрямую с файлами баз данных всегда несут риск повреждения. Прежде чем выполнять VACUUM, мы должны скопировать файл 1Cv8.lgd в безопасное место.
sqlite3.exe:
Нам потребуется официальная утилита командной строки sqlite3.exe. Мы можем скачать ее с официального сайта sqlite.org (например, в составе пакета sqlite-tools-win32-x86-...zip).
Распаковываем скачанный архив в любое удобное место на сервере или рабочей станции, где у нас есть доступ к файлу 1Cv8.lgd.
Мы открываем командную строку (cmd.exe), желательно с правами администратора. Переходим в каталог, куда мы распаковали sqlite3.exe, используя команду cd <путь_к_папке_sqlite>.
VACUUM:
В командной строке мы выполняем следующую команду, указывая полный путь к нашему файлу 1Cv8.lgd:
sqlite3.exe "C:\<путь_к_файлу>\1Cv8.lgd" vacuum;
Важно: Не забываем кавычки, если путь содержит пробелы, и точку с запятой в конце команды. Если мы скопировали sqlite3.exe непосредственно в папку с 1Cv8.lgd, и путь не содержит русских символов, можно просто выполнить: sqlite3.exe 1Cv8.lgd vacuum;
Операция VACUUM может занять значительное время, особенно для больших файлов (файл размером 4 ГБ может обрабатываться до 30 минут). Мы дожидаемся завершения процесса.
После успешного выполнения команды VACUUM мы перезапускаем службу агента сервера 1С:Предприятия.
Помимо основных методов, есть и другие подходы, которые мы можем рассмотреть для further оптимизации работы с журналом регистрации.
Мы можем включить сжатие NTFS для папки 1Cv8Log. Это позволит операционной системе автоматически сжимать файлы в этой папке, что сэкономит дисковое пространство. Мы можем сделать это, перейдя в свойства папки 1Cv8Log, затем в "Дополнительно..." и установив флажок "Сжимать содержимое для экономии места на диске". Это простое и быстрое решение, но оно может незначительно увеличить нагрузку на процессор при чтении/записи данных.
Для повышения производительности и снижения нагрузки на основные диски мы можем рассмотреть перенос папки журнала регистрации на отдельный физический диск, желательно с высокой скоростью записи (например, SSD). В некоторых случаях, для очень высоконагруженных систем, можно использовать RAM-диск, что обеспечит максимальную скорость, но требует достаточного объема оперативной памяти и механизма сохранения данных RAM-диска при перезагрузке.
Если это применимо и возможно, мы можем исключить из логирования реквизиты объектов, которые потенциально могут содержать очень большие объемы данных, такие как хранилища значений, двоичные данные (файлы, картинки) или длинные текстовые поля. Такую настройку необходимо выполнять в конфигурации, что требует знаний программирования 1С.
Мы должны убедиться, что все регламентные задания настроены таким образом, чтобы не создавать чрезмерную нагрузку на сервер и не записывать слишком много избыточной информации в журнал. Некоторые задания могут генерировать подробные отчеты или протоколы, которые попадают в журнал, если уровень логирования установлен слишком высоко.
Для долгосрочной стабильности работы системы мы должны разработать и следовать четкому регламенту по управлению журналом регистрации. Например, хранить полный журнал за последнюю рабочую неделю, затем только изменения или агрегированные данные, а более старые записи архивировать или удалять. Это поможет нам поддерживать баланс между доступностью информации для анализа и эффективным использованием дискового пространства.
Быстрый рост файла журнала регистрации 1С:Предприятия – это распространенная проблема, которая имеет несколько причин и, к счастью, множество эффективных решений. От понимания формата журнала до настройки его детализации и выключения "Замера производительности" – каждый шаг важен. Мы должны помнить, что перед выполнением любых серьезных изменений, особенно связанных с файлами журнала или остановкой серверных служб, крайне важно сделать резервные копии информационной базы и самих файлов журнала регистрации. Комплексный подход к решению этой проблемы позволит нам значительно улучшить стабильность и производительность нашей системы 1С:Предприятие.