Как остановить бесконечное создание временных файлов v8_*.tmp в папке TEMP сервера 1С?

← На главную

Ситуация, когда папка временных файлов (TEMP) на сервере 1С:Предприятие начинает стремительно заполняться тысячами пустых файлов вида v8_513E_1ad8c.tmp, является критической для стабильности системы. Это не просто занимает место на диске (для контроля ситуации рекомендуем использовать мониторинг серверов), но и создает колоссальную нагрузку на файловую подсистему, замедляет работу операционной системы и может привести к полной остановке службы rphost. Разберем подробно, почему это происходит и как устранить проблему по шагам.

Анализ первопричины: механизм слияния индексов

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

Полнотекстовый поиск в 1С постоянно обновляет свои данные. Существует основной индекс (большой) и дополнительные индексы (небольшие порции новых данных). В определенный момент система запускает процедуру «слияния», чтобы объединить их. Если файлы индекса повреждены на физическом уровне или заблокированы, 1С входит в бесконечный цикл попыток, создавая мусорные временные файлы при каждой итерации.

Решение №1: Очистка и пересоздание индекса полнотекстового поиска

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

Отключение регламентного задания: В консоли администрирования 1С или через обработку «Регламентные и фоновые задания» найдем задание ОбновлениеИндексаПолнотекстовогоПоиска и СлияниеИндексаПолнотекстовогоПоиска. Отключим их на время проведения работ.
Очистка через интерфейс: В самой программе (в режиме «1С:Предприятие») перейдем в раздел Администрирование — Поддержка и обслуживание — Управление полнотекстовым поиском. Нажмем кнопку «Очистить индекс».
Физическое удаление файлов: Часто программной очистки недостаточно, если файлы заблокированы. Рассмотрим радикальный, но эффективный метод:
- Остановим службу 1C:Enterprise 8.3 Server Agent.
- Перейдем в каталог информационной базы на сервере (обычно это папка внутри srvinfo\reg_1541\...).
- Найдем папку с именем Index и полностью удалим её содержимое.
- Запустим службу сервера 1С.
Полное пересоздание: После запуска службы вернемся в управление полнотекстовым поиском и нажмем «Обновить индекс». Система заново просканирует базу и создаст корректные файлы без ошибок.

Решение №2: Диагностика с помощью Process Monitor (ProcMon)

Если очистка индекса не помогла, нам нужно точно выяснить, какой поток внутри rphost инициирует создание файлов. Для этого воспользуемся утилитой Process Monitor. Разберем алгоритм настройки фильтров:

Запустим утилиту и установим следующие правила фильтрации:

Process Name is rphost.exe
Operation is CreateFile
Path contains \Temp\v8_

Проанализируем результат. В колонке Detail мы увидим, с какими параметрами открывается файл. Но самое важное — это Stack Trace (двойной клик по строке события, вкладка Stack). Проанализировав стек вызовов, можно понять, какая библиотека или модуль 1С инициирует обращение. Например, если в стеке видны обращения к dbms, проблема в запросах к СУБД (здесь пригодится анализ SQL сервера глазами 1С-ника); если к files — в работе с хранилищем или индексами.

Решение №3: Настройка Технологического журнала

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


<config xmlns="http://v8.1c.ru/7.4/config/logcfg">
  <log location="C:\1C_Logs\TempFilesIssue" history="2">
    <event>
      <eq property="Name" value="EXCP"/>
    </event>
    <event>
      <eq property="Name" value="PROC"/>
    </event>
    <property name="All"/>
  </log>
</config>

Рассмотрим, что это нам даст. Событие EXCP зафиксирует все неявные ошибки, которые не видит пользователь, но которые прерывают работу фоновых процессов. Именно в момент EXCP часто бросается открытый временный файл, который превращается в «мусор». Поток (Thread ID) из ТЖ можно сопоставить с данными из Process Monitor для получения полной картины.

Решение №4: Проверка внешних факторов (Антивирус и права доступа)

Иногда причина кроется не в самой 1С, а в окружении. Выясним, не мешает ли что-то серверу 1С корректно удалять свои временные файлы:

Антивирусное ПО: Рассмотрим ситуацию, когда антивирус сканирует каждый новый файл в папке TEMP. В момент, когда rphost создает файл v8_*.tmp, антивирус его перехватывает для проверки. Если в этот же микромомент 1С пытается его удалить или изменить, возникает конфликт блокировок. Файл остается «висеть» в статусе 0 байт. Решение: Добавьте папку временных файлов пользователя, под которым работает служба 1С, в исключения антивируса.
Права доступа: Убедимся, что у учетной записи, от которой запущена служба 1C:Enterprise Agent, есть полные права (Full Control) на папку TEMP.

Решение №5: Анализ фоновых заданий и COM-соединений

Если проблема не в полнотекстовом поиске, проверим активность фоновых заданий. В консоли кластера обратим внимание на количество сеансов и их длительность. Если мы видим сотни кратковременных сеансов, которые появляются и исчезают, это может быть признаком:

Зацикленного фонового задания: Ошибка в коде приводит к тому, что задание падает и тут же перезапускается планировщиком.
Внешних HTTP/Web-запросов: Если база опубликована, внешние системы могут заваливать её запросами. Каждый запрос создает временный файл для хранения контекста. Посмотрим логи IIS или Apache, чтобы исключить этот фактор.
COM-соединений: Использование COMConnector внутри циклов без явного освобождения памяти и завершения соединения также порождает утечку временных файлов. Проанализируем код на наличие конструкций типа Новый COMОбъект("V83.COMConnector").