Как почистить логи сервера 1С 8.3

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

Проблема в том, что «логи 1С» — это не один файл, а несколько разных хранилищ с разной логикой очистки. Журнал регистрации сокращается штатными средствами конфигуратора, технологический журнал управляется файлом настроек logcfg.xml, логи СУБД (MS SQL или PostgreSQL) чистятся вообще другими инструментами. Удалять всё подряд через проводник — плохая идея: часть файлов открыта работающими службами, а часть нужна для расследования инцидентов.

Ниже разобраны все основные типы логов, безопасные способы их очистки, настройка ротации, чтобы проблема не возвращалась, и типичные ошибки администраторов. Материал ориентирован на клиент-серверный вариант работы, но часть приёмов применима и к файловым базам.

Какие логи есть у сервера 1С и где они лежат

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

• Журнал регистрации — файл 1Cv8.lgd в каталоге информационной базы (в клиент-серверном варианте — в каталоге базы внутри srvinfo, обычно C:\Program Files\1cv8\srvinfo\reg_1541\<GUID базы> или аналогичный путь на Linux в /home/usr1cv8/.1cv8).
• Технологический журнал — каталог, заданный в logcfg.xml (по умолчанию часто C:\Program Files\1cv8\srvinfo\logs или conf\logs), с подкаталогами по процессам rphost, rmngr, ragent.
• Дампы аварийных завершений — каталог dumps, путь задаётся там же в logcfg.xml; файлы .mdmp могут весить сотни мегабайтов каждый.
• Логи кластера и агента — служебные файлы в srvinfo, включая журналы регистрации самого кластера.
• Логи СУБД — журнал транзакций MS SQL (.ldf), логи ошибок SQL Server, pg_log у PostgreSQL. Это отдельная тема, но именно они чаще всего «съедают» диск.

Быстро оценить, что занимает место, помогает простой просмотр размеров каталогов srvinfo и каталогов СУБД. Если основной объём — подкаталоги с именами процессов и файлами .log, это техножурнал. Если один большой файл 1Cv8.lgd — журнал регистрации. Если .ldf — журнал транзакций MS SQL.

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

Журнал регистрации — единственный лог, для которого есть штатный инструмент сокращения. Удалять файл 1Cv8.lgd вручную нельзя: это приведёт к потере всей истории событий и, при некорректных действиях, к ошибкам открытия журнала.

Порядок действий: откройте конфигуратор под пользователем с правами администратора, перейдите в Администрирование → Обслуживание → Журнал регистрации, затем нажмите Сократить. В диалоге выберите дату, до которой удалять события, и обязательно укажите файл для сохранения удаляемых событий — так старая история останется доступной для расследований, но не будет занимать место в рабочем журнале.

1. 1
   Сделайте резервную копию базы или хотя бы скопируйте файл 1Cv8.lgd
2. 2
   Откройте конфигуратор → Администрирование → Обслуживание → Журнал регистрации
3. 3
   Нажмите «Сократить», укажите дату отсечения и файл для сохранения старых событий
4. 4
   Дождитесь завершения — на больших журналах операция может занять десятки минут
5. 5
   Проверьте, что журнал открывается и новые события записываются

Важный нюанс: на больших журналах (несколько гигабайт) сокращение идёт долго и требует монопольного доступа к файлу журнала. В клиент-серверном варианте это обычно не блокирует работу пользователей полностью, но лучше выполнять операцию в нерабочее время. Если журнал достиг критического размера и конфигуратор не справляется, альтернатива — перевести базу на новый формат журнала (SQLite-файл 1Cv8.lgd нового формата создаётся при смене режима в свойствах базы через консоль кластера или при выгрузке/загрузке), но это уже операция уровня опытного администратора.

Очистка технологического журнала и настройка logcfg.xml

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

Структура каталога техжурнала: внутри заданного пути создаются подкаталоги по именам процессов (rphost_*, rmngr_*, ragent_*), а в них — файлы вида yyMMddHH.log (по часам). Удаляйте каталоги и файлы старше нужной даты обычными средствами ОС. Текущий часовой файл лучше не трогать.

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

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:\1clogs" history="72">
    <event><eq property="name" value="EXCP"/></event>
    <property name="all"/>
  </log>
  <dump create="false"/>
</config>

Здесь history="72" означает хранение логов за 72 часа — всё старше сервер удалит сам. Секция <dump create="false"/> отключает создание дампов, если они не нужны. После изменения logcfg.xml перезапуск службы агента сервера не обязателен — конфигурация подхватывается автоматически в течение примерно минуты.

Если техножурнал включали временно для диагностики конкретной проблемы — после сбора данных удалите или переименуйте logcfg.xml. Это самая частая причина переполнения диска: диагностический сбор забыли выключить, и за месяц журнал вырос до сотен гигабайт.

Удаление дампов и служебных файлов кластера

Дампы аварийных завершений (.mdmp) создаются, когда процесс rphost падает. Каждый дамп может занимать от сотен мегабайт до нескольких гигабайт. Если падения разовые и причина уже найдена, старые дампы можно удалять без сомнений. Если падения регулярные — сохраните пару свежих дампов для анализа (их может запросить техническая поддержка или они понадобятся для анализа через отладчик), остальное удалите.

Путь к дампам указывается в logcfg.xml; если он не задан, дампы могут складываться в каталог srvinfo или системный каталог аварийных дампов Windows. Проверьте оба места.

Отдельно стоит упомянуть каталоги сеансовых данных и временные файлы в srvinfo. Каталоги вида snccntx и временные файлы сеансов при штатной работе очищаются самим сервером, но после аварийных остановок там могут оставаться остатки. Удалять их следует только при остановленной службе агента сервера — иначе можно нарушить работу активных сеансов.

Логи СУБД: MS SQL и PostgreSQL

Часто «логи сервера 1С» на самом деле означают разросшийся журнал транзакций MS SQL. Если база работает в полной модели восстановления (Full), а резервные копии журнала транзакций не делаются, файл .ldf растёт бесконечно и может превысить размер самой базы.

Для баз 1С, где не требуется восстановление на произвольный момент времени, стандартная практика — перевести базу в простую модель восстановления (Simple): в SQL Server Management Studio — свойства базы → Параметры → Модель восстановления. После переключения журнал можно сжать: правой кнопкой по базе → Задачи → Сжать → Файлы → выбрать файл журнала. В простой модели журнал усекается автоматически и больше не будет расти без контроля.

Если полная модель нужна (требования по восстановлению на точку времени), то решение — не чистка, а регулярное резервное копирование журнала транзакций: именно бэкап журнала усекает его. Настройте задание в плане обслуживания с интервалом, соответствующим интенсивности работы.

У PostgreSQL проверьте каталог pg_log (или log, в зависимости от версии и настроек) — текстовые логи сервера. Настройте ротацию параметрами log_rotation_age и log_rotation_size в postgresql.conf, старые файлы удаляйте вручную. Журналы WAL (pg_wal) трогать вручную категорически нельзя — их удаление разрушит базу.

Автоматизация очистки и профилактика

Разовая чистка решает проблему на неделю. Чтобы не возвращаться к ней каждый месяц, настройте автоматику. Для техножурнала достаточно параметра history в logcfg.xml — сервер сам удаляет устаревшие файлы. Для дампов и прочих старых файлов удобно использовать планировщик Windows с простым скриптом.

# Удаление файлов техжурнала и дампов старше 7 дней
$paths = @('C:\1clogs', 'C:\Program Files\1cv8\srvinfo\dumps')
foreach ($p in $paths) {
  if (Test-Path $p) {
    Get-ChildItem $p -Recurse -File |
      Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-7) } |
      Remove-Item -Force -ErrorAction SilentlyContinue
  }
}

Для журнала регистрации автоматизации штатными средствами нет — сокращение выполняется вручную. Разумный компромисс: поставить напоминание раз в квартал или контролировать размер 1Cv8.lgd мониторингом. Также в свойствах базы в консоли кластера можно ограничить уровень записываемых событий, но делать это стоит осознанно: отключение регистрации событий изменения данных лишает вас аудита.

Проверка результата и границы безопасной работы

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

Безопасная граница самостоятельной работы: сокращение журнала регистрации, удаление старых файлов техжурнала и дампов, настройка logcfg.xml, смена модели восстановления и сжатие журнала MS SQL. Если же диск заполнен, а причина неясна, база не открывается после чистки или журнал регистрации повреждён — это повод остановиться, снять копию текущего состояния и привлечь специалиста по администрированию 1С или СУБД. Попытки «починить» srvinfo или файлы базы вручную без опыта чаще усугубляют ситуацию.

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