Логи 1С разрослись до гигабайт: как освободить место на диске

Место на диске съедают три вещи: технологический журнал (каталог, заданный в logcfg.xml), журнал регистрации базы (файл 1Cv8.lgd либо старые .lgf/.lgp) и дампы аварий (папка dumps). Чтобы уменьшить лог-файлы 1С, определите, какой из трёх разросся, и работайте именно с ним — удалять всё подряд не нужно.

Самый частый случай — кто-то включил технологический журнал для диагностики и забыл выключить. За недели он набирает десятки гигабайт. Ниже — что безопасно удалить руками, как настроить автоматическую ротацию логов и как перенести их на отдельный диск, чтобы проблема не вернулась.

Три вида логов 1С и где они лежат

Прежде чем чистить, поймите, что именно разрослось. У платформы три независимых источника логов, и каждый чистится по-своему.

Файл logcfg.xml в файловом и клиент-серверном вариантах лежит в каталоге conf платформы, обычно это C:\Program Files\1cv8\conf\logcfg.xml. Если файла нет — технологический журнал не ведётся, и его каталог искать бессмысленно. Это главный виновник «вдруг кончилось место»: журнал включают на пару дней для разбора проблемы, а выключить забывают.

Журнал регистрации у файловой базы хранится в папке 1Cv8Log внутри каталога базы. У серверной базы он на компьютере с кластером, в каталоге сервера — по умолчанию C:\Program Files\1cv8\srvinfo\<имя сервера>\<идентификатор базы>\1Cv8Log. В актуальных версиях платформы это один файл 1Cv8.lgd (формат SQLite); в старых — набор файлов .lgf и .lgp.

Безопасная ручная чистка: что можно удалить, а что нет

Руками удаляют файлы технологического журнала и старые дампы — это безопасно: платформа создаст их заново при необходимости.

Что удалять можно:

• 📁 содержимое каталога технологического журнала (подпапки по процессам и файлы .log);
• 📁 содержимое папки dumps — старые дампы *.mdmp;
• 📁 устаревшие файлы .lgp старого формата журнала регистрации (данные за прошедшие периоды).

Чего НЕ делайте:

• ❌ не удаляйте активный файл 1Cv8.lgd или .lgf, пока база в работе — журнал может повредиться;
• ❌ не трогайте сам logcfg.xml и папку conf;
• ❌ не чистите журнал регистрации через проводник, если нужна его история для аудита — записи так не сохранить.

Обычно самое тяжёлое — подпапки техжурнала с именами вида rphost_NNNN и rmngr_NNNN: это процессы сервера. Внутри — файлы .log по часам. Удалять их можно целиком; каталог верхнего уровня (тот, что в location) оставьте — платформа создаст подпапки заново. Папка dumps с файлами *.mdmp чистится так же.

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

Разовая чистка освободит диск сегодня, но без ротации логи наберут объём снова. Поэтому дальше — автоматика.

Ротация технологического журнала через logcfg.xml

Технологический журнал чистит себя сам, если задать срок хранения. За это отвечает атрибут history в элементе <log> — число часов, после которых файлы удаляются автоматически.

Минимальный logcfg.xml с ротацией и выносом на отдельный диск:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\1c-logs\techlog" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <property name="all"/>
  </log>
  <dump location="D:\1c-logs\dumps" create="1" type="3"/>
</config>

Разберём ключевое:

• location — каталог для логов. Вынесите его на диск с запасом места, не на системный C:.
• history="24" — хранить 24 часа. Для рабочей диагностики хватает 24–72 часов; чем меньше число, тем меньше объём.
• <event> — какие события писать. В примере только исключения (EXCP). Чем шире фильтр событий, тем быстрее растёт журнал.

После правки logcfg.xml перезапускать службу не обязательно — платформа перечитывает файл в течение минуты. Проверьте, что в каталоге location начали появляться свежие папки.

Какие события писать — решает фильтр <event>. От их набора объём зависит в разы:

Фильтры задаются элементами сравнения: <eq property="name" value="EXCP"/> пишет только указанное событие, <ne .../> — всё, кроме него. Фильтр по событиям CALL и SDBL без ограничения по времени за сутки набирает гигабайты — включайте их точечно и сразу выключайте.

Сокращение журнала регистрации в конфигураторе

Журнал регистрации правильно чистить не через проводник, а из конфигуратора — так данные не повредятся и при желании сохранятся в файл.

Порядок действий:

1. Откройте базу в конфигураторе.
2. Меню Администрирование → Настройка журнала регистрации.
3. В открывшемся окне нажмите кнопку сокращения журнала.
4. Укажите дату: записи старше неё будут удалены. При необходимости поставьте галку выгрузки удаляемых записей в файл — так сохраните историю на случай аудита.

Там же задаётся период разделения журнала: день, неделя, месяц, год или «не разделять». Разделение по дню или неделе делает старые записи удобными для удаления и ускоряет открытие журнала на больших базах.

Если база работает в старом формате журнала (набор файлов .lgf и .lgp вместо одного 1Cv8.lgd), сокращение из конфигуратора тоже сработает. Файлы .lgp хранят данные за конкретные периоды — после сокращения лишние уйдут. Перевести базу на компактный формат 1Cv8.lgd можно в той же форме настройки журнала; единый SQLite-файл занимает меньше места и быстрее открывается.

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

Снижение уровня логирования, чтобы логи не росли

Чистить проще то, что медленно растёт. Уменьшите объём на входе.

Для технологического журнала:

• оставьте в logcfg.xml только нужные события (EXCP — исключения, DBMSSQL — запросы к СУБД при разборе медленных запросов) вместо «пишем всё»;
• не держите включённым сбор планов запросов и полнотекстовые свойства на постоянной основе — это главные пожиратели места;
• выключайте журнал сразу после диагностики, а не «пусть ещё повисит».

Для журнала регистрации в настройках (Администрирование → Настройка журнала регистрации) можно отключить регистрацию части событий — например, не писать все обращения к данным, если аудит этого не требует. Чем меньше классов событий пишется, тем медленнее растёт 1Cv8.lgd.

Отдельно про дампы: если dumps раздувается, значит у платформы регулярные аварийные завершения. Удаление дампов — симптоматика; причину (сбойный процесс, нехватка памяти) стоит разобрать отдельно, а сбор полных дампов (type="3") переключить на мини-дампы, если место критично.

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

Планировщик задач Windows: чистка по расписанию

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

Команда удаляет из каталога всё старше 7 дней:

forfiles /p "D:\1c-logs\dumps" /s /m *.mdmp /d -7 /c "cmd /c del @path"

• /p — каталог; /s — включая подпапки;
• /m *.mdmp — маска файлов (для техжурнала — *.log);
• /d -7 — старше 7 дней;
• /c "cmd /c del @path" — что сделать с каждым найденным файлом.

Как поставить на расписание:

1. Сохраните команду в .bat-файл, например clean_1c_logs.bat.
2. Откройте «Планировщик заданий» Windows (taskschd.msc).
3. Создайте задачу, триггер — ежедневно ночью, действие — запуск вашего .bat.
4. Запустите задачу вручную один раз и проверьте, что файлы удаляются.

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

Если логи нужны для истории, но занимают много места, их архивируют и выносят с системного диска.

Перенос технологического журнала и дампов делается одной правкой — укажите в logcfg.xml путь location на другом диске (см. пример выше). Платформа начнёт писать туда; старый каталог после этого можно удалить.

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

Архивирование старых файлов:

• файлы техжурнала и выгруженные записи журнала регистрации хорошо жмутся в .zip или .7z — текст сжимается в разы;
• добавьте в тот же .bat упаковку перед удалением, если история нужна;
• храните архивы на отдельном томе или в сетевом хранилище, а не рядом с базой.

Если под техжурнал и дампы выделен отдельный том, следите за его свободным местом так же, как за системным. Переполненный диск с логами при включённом сборе может замедлить саму платформу. Разумная схема: history на сутки-двое, задача forfiles на дампы, а раз в неделю — упаковка того, что нужно сохранить, в архив на другом томе.

Итог простой: history в logcfg.xml закрывает техжурнал, конфигуратор — журнал регистрации, forfiles в планировщике — дампы и архивы. Настроив всё это один раз, вы больше не вернётесь к ручной чистке переполненного диска.

Частые вопросы