Как остановить автоматическое создание файла logcfg.xml и переполнение диска на сервере 1С

Администраторы серверов 1С часто сталкиваются с ситуацией, когда на диске сервера стремительно заканчивается свободное место. Скорость заполнения диска может достигать десятков гигабайт в сутки. При этом в системных папках или каталоге TEMP бесконтрольно создаются файлы дампов и технологического журнала, а ручное удаление конфигурационного файла logcfg.xml не приносит результатов — он создается снова автоматически. В этой статье мы подробно разберем, почему это происходит, как обнаружить источник проблемы и навсегда остановить этот процесс.

Выясняем причину: откуда берется файл logcfg.xml

Файл logcfg.xml является основным конфигурационным файлом технологического журнала 1С. Он определяет, какие именно события системы должны записываться в логи, куда сохранять эти данные и в каком объеме. Обычно этот файл создается администратором вручную для расследования технологических проблем. Однако бывают случаи, когда файл создается автоматически без ведома администратора.

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

<config xmlns="http://v8.1c.ru/v8/tech-log">
    <dump location="C:\TEMP\Dumps\80af5716-b134-4b1c-a38d-4658d1ac4196\" create="true" />
</config>

Обратите внимание на уникальный идентификатор (GUID) в пути сохранения дампов: 80af5716-b134-4b1c-a38d-4658d1ac4196. Этот идентификатор не генерируется случайно. Он жестко зашит в коде официальной внешней обработки «Консоль запросов для управляемого приложения» (RequestConsoleManaged.epf), распространяемой на дисках и портале ИТС.

Рассмотрим механизм работы этой консоли подробнее. В консоли запросов реализована функция получения планов выполнения запросов на уровне СУБД. При включении этой функции (а в некоторых версиях обработки — непосредственно при ее открытии) программный код обработки обращается к серверу и создает файл logcfg.xml в каталоге установки платформы (например, в C:\Program Files\1cv8\conf\logcfg.xml) или в профиле пользователя операционной системы, под которым запущен рабочий процесс 1С. В этот файл прописываются настройки для генерации дампов при определенных условиях.

По задумке разработчиков, при закрытии обработки или отключении замера планов запросов файл logcfg.xml должен автоматически удаляться или очищаться. Однако на практике этот механизм часто дает сбой по следующим причинам:

• Аварийное завершение сеанса. Если пользователь просто закрыл окно веб-клиента или тонкого клиента крестиком, сеанс завис или связь с сервером прервалась, обработка не успевает выполнить код очистки конфигурационного файла.
• Некорректный выход из RDP. При закрытии терминальной сессии процесс 1С может аварийно завершиться, оставив настройки техжурнала активными.
• Зависание фонового задания. Если замер планов выполнялся в фоновом режиме и задание зависло, процесс генерации логов будет продолжаться непрерывно.

Пока в системе остается активным сеанс, вызвавший данную обработку, любые попытки вручную удалить logcfg.xml будут тщетными — рабочий процесс 1С (rphost.exe) моментально пересоздаст его заново.

Проверим также альтернативные папки, где может находиться этот файл, помимо стандартного каталога C:\Program Files\1cv8\conf\:

• Каталог конкретной версии платформы: C:\Program Files\1cv8\8.3.X.XXXX\bin\conf\.
• Профиль пользователя, под которым работает служба сервера 1С (например, USR1CV8): C:\Users\USR1CV8\AppData\Local\1C\1cv8\conf\.
• Каталог, переопределенный в файле conf.cfg с помощью параметра ConfDir.

---

Вторая проблема: почему диск забивается на 20 ГБ в сутки

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

1. Генерация аварийных дампов рабочих процессов. Если в файле logcfg.xml активен тег <dump> с параметром create="true", то при любой критической ошибке, утечке памяти или аварийном завершении рабочего процесса rphost.exe платформа выгружает всю свою оперативную память в файл дампа (с расширениями .dmp или .mdmp). Если база данных тяжелая, а процессов на сервере много, то каждое падение генерирует файлы размером от нескольких сотен мегабайт до десятков гигабайт. При циклическом перезапуске процессов диск заполняется мгновенно.
2. Сбои в работе Полнотекстового поиска (ПП). Временные файлы полнотекстового поиска по умолчанию также сохраняются в системный каталог TEMP. Во время индексации больших объемов данных или при повреждении индекса регламентные задания по обновлению и слиянию индекса могут уходить в бесконечный цикл. Это вызывает колоссальную нагрузку на дисковую подсистему (диск начинает непрерывно свопить) и провоцирует падение процессов rphost.exe, что, в свою очередь, заставляет систему создавать новые и новые файлы дампов.

---

Пошаговое руководство по решению проблемы

Давайте разберем по шагам, как локализовать источник проблемы, остановить запись логов и освободить дисковое пространство.

Шаг 1. Поиск и принудительное завершение виновного сеанса

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

1. Откройте консоль Администрирование серверов 1С Предприятия.
2. Перейдите в ветку вашего кластера, далее откройте раздел Сеансы.
3. Проанализируйте колонку Приложение и имя пользователя. Ищите сеансы с запущенной «Консолью запросов» или сеансы администраторов, запущенные через тонкий/толстый клиент.
4. Обратите внимание на фоновые задания. Завершите подозрительные сеансы, нажав правой кнопкой мыши и выбрав пункт Удалить (или завершить).

Шаг 2. Точное определение процесса-источника через Process Monitor

Если сеансов на сервере много и визуально определить виновника не удается, воспользуемся бесплатной системной утилитой Process Monitor (ProcMon) от Microsoft Sysinternals.

1. Скачайте и запустите утилиту ProcMon на сервере 1С от имени Администратора.
2. Настройте фильтрацию событий, чтобы не утонуть в потоке системных вызовов. Для этого нажмите кнопку Filter (или комбинацию клавиш Ctrl+L).
3. Добавьте следующее правило фильтрации: Path contains logcfg.xml -> then Include. Нажмите кнопку Add, затем Apply.
4. Попробуйте вручную удалить файл logcfg.xml из папки conf.
5. В окне ProcMon мгновенно отобразится строка обращения к этому файлу. Обратите внимание на колонку Process Name (там будет указан rphost.exe) и колонку PID (идентификатор процесса).
6. Вернитесь в консоль администрирования 1С, перейдите в раздел Рабочие процессы, найдите процесс с зафиксированным PID. В свойствах процесса вы увидите список подключений и сеансов, которые обслуживает данный рабочий процесс. Завершите эти сеансы.

Шаг 3. Очистка и перезапуск Полнотекстового поиска

Если основной объем диска занимают файлы в папках с названиями FTindex или временные файлы с расширением .dat, нам необходимо сбросить индекс полнотекстового поиска.

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

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

Если ПолнотекстовыйПоиск.ПолучитьРежимИспользования() <> РежимИспользованияПолнотекстовогоПоиска.НеИспользовать Тогда
    ПолнотекстовыйПоиск.УстановитьРежимИспользования(РежимИспользованияПолнотекстовогоПоиска.НеИспользовать);
    ЗаписьЖурналаРегистрации("НастройкаСистемы", УровеньЖурналаРегистрации.Информация, , , "Полнотекстовый поиск успешно отключен.");
КонецЕсли;

Шаг 4. Настройка лимитов для предотвращения падений rphost

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

1. В консоли администрирования 1С откройте свойства вашего локального кластера (обычно это Локальный кластер).
2. Установите параметр Допустимый объем памяти. Рекомендуется рассчитывать его исходя из общего объема оперативной памяти сервера и количества рабочих процессов. Например, установите значение 4194304 КБ (4 ГБ) на один процесс.
3. Установите параметр Интервал перезапуска в значение 86400 секунд (24 часа). Это позволит процессам автоматически и незаметно для пользователей завершать свою работу и освобождать заблокированную память раз в сутки.
4. Задайте параметр Выключать процессы с памятью более (например, 5 ГБ), чтобы принудительно гасить процессы с утечками до того, как они вызовут критический сбой всей операционной системы.

Шаг 5. Принудительное ограничение размера логов в logcfg.xml

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

<config xmlns="http://v8.1c.ru/v8/tech-log">
    <!-- Настройка сбора технологического журнала -->
    <log location="C:\TEMP\1C_Logs" history="24">
        <event>
            <eq property="Name" value="EXCP"/>
        </event>
        <property name="all"/>
    </log>
    <!-- Настройка создания дампов с ограничением их количества -->
    <dump create="true" location="C:\TEMP\Dumps" maxfiles="5" PrntLogs="true" />
</config>

В данном конфигурационном файле:

• Параметр history="24" указывает платформе автоматически удалять файлы технологического журнала, которые были созданы более 24 часов назад.
• Параметр maxfiles="5" ограничивает максимальное количество одновременно хранящихся файлов дампов в каталоге. При создании шестого дампа самый старый будет автоматически удален.

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