← На главную

Многие системные администраторы и специалисты 1С сталкиваются с ситуацией, когда дисковое пространство на сервере тает на глазах. Особенно критично это проявляется в каталоге reg_1541, где хранятся данные кластера серверов 1С. Ситуация, когда папка вырастает с 2 ГБ до 50 ГБ и более всего за несколько часов, чаще всего свидетельствует о техническом сбое в работе платформы или некорректно настроенных сервисных функциях. В этой статье мы подробно разберем причины такого поведения и пошагово внедрим решения для стабилизации системы.

Причина 1: Критический баг полнотекстового поиска (ППД) в платформе 8.3.25

Проанализируем ситуацию: если вы используете платформу версии 8.3.25.1501 (или близкие к ней сборки), вы почти наверняка столкнулись с официально признанной ошибкой индексации. В механизме полнотекстового поиска возникает циклическая запись, из-за которой временные файлы начинают бесконтрольно расти.

Выясним причину: внутри папки каждой базы (каталоги с GUID) есть подпапка 1Cv8FTxt. В норме файл tableChanges.dat является временным и должен удаляться после обновления индекса. Однако из-за бага он «запирается» и аккумулирует гигантские объемы данных.

Что необходимо сделать:

1. Рассмотрим радикальное, но самое надежное решение — обновление платформы. Ошибка устранена в версии 8.3.25.1546 и выше.
2. Если оперативное обновление невозможно, выполним ручную очистку. Для этого остановим службу 1C:Enterprise 8.3 Server Agent.
3. Перейдем в каталог C:\Program Files\1cv8\srvinfo\reg_1541, найдем папки информационных баз и полностью удалим содержимое всех папок 1Cv8FTxt.
4. После запуска службы заново перейдем в консоль администрирования (удобно через панель управления кластером серверов и сеансами) или в саму программу и инициируем полное пересоздание индекса через управление полнотекстовым поиском.

Причина 2: Избыточное логирование в Журнале регистрации

Разберем влияние журнала регистрации (ЖР) на дисковую подсистему. В современных конфигурациях, таких как ЗУП и БУХ, происходит огромное количество фоновых операций. Если уровень детализации журнала настроен на «Регистрировать всё», файл 1Cv8.lgd (формат SQLite) может расти скачкообразно. Для понимания того, какие именно процессы создают нагрузку, можно использовать анализ журнала регистрации — для этого есть система мониторинга ошибок в журнале регистрации.

Особенность формата SQLite заключается в том, что при интенсивной записи создаются вспомогательные файлы -wal (Write-Ahead Log) and -shm (Shared Memory). При выполнении тяжелых регламентных заданий (например, закрытие месяца или пересчет зарплаты) эти файлы могут достигать десятков гигабайт.

Настроим журнал регистрации правильно:

1. Зайдем в информационную базу в режиме «Конфигуратор».
2. Откроем пункт меню «Администрирование» — «Настройка журнала регистрации».
3. Установим режим «Регистрировать только ошибки» или вовсе отключим регистрацию событий, если они не критичны для аудита в данный момент.
4. Для физического уменьшения уже разросшегося файла 1Cv8.lgd используем штатную процедуру сокращения журнала (Администрирование — Выгрузить журнал регистрации и удалить старые записи). Предварительно данные можно сохранить во внешние хранилища, выполнив выгрузку журнала регистрации в Excel или настроив экспорт журнала в Clickhouse.

Причина 3: Утечка сеансовых данных (snccntx)

Посмотрим на содержимое папок вида snccntx<GUID>. Здесь 1С хранит данные сеансов, которые не поместились в оперативную память. Если в системе работают тяжелые отчеты или происходят аварийные разрывы соединений, платформа может «забывать» удалять эти временные файлы.

Проанализируем ситуацию: в версии 8.3.25 замечен эффект «брошенных» файлов сеансов. Даже после выхода пользователя из системы файлы продолжают занимать место. Единственный способ эффективно бороться с этим без обновления платформы — периодическая очистка при остановленной службе сервера 1С. Для автоматизации процесса очистки места на диске можно использовать удаление файлов из программы 1С — в этом поможет универсальный инструмент администрирования и работы с файлами.

Причина 4: Аварийные дампы памяти (dmp-файлы)

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

Проверим наличие дампов:

1. Поищем в папке srvinfo файлы с расширением .dmp.
2. Если их много, значит, ваша платформа работает нестабильно. Рекомендуется проанализировать технологический журнал (поможет утилита анализа производительности и технологического журнала) или просто удалить эти файлы, чтобы освободить место.
3. Для предотвращения их появления в будущем можно настроить сбор дампов в операционной системе, ограничив их размер или количество.

Причина 5: Конфликт с антивирусным ПО

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

Добавим исключения:

Необходимо добавить в список исключений (исключить из проверки в реальном времени):

• Весь каталог C:\Program Files\1cv8\srvinfo\.
• Исполняемые файлы процессов rphost.exe, rmngr.exe, ragent.exe.
• Расширения файлов .1cd, .lgd, .lgp.

Подведем итог и составим план действий

Для решения проблемы резкого разрастания папки reg_1541 мы рекомендуем придерживаться следующего алгоритма:

1. Остановка службы: Прекратим работу сервера 1С.
2. Очистка кэша и индексов: Удалим содержимое папок 1Cv8FTxt и snccntx. Это безопасно, так как индекс перестроится сам, а данные сеансов будут созданы заново при входе пользователей.
3. Проверка дампов: Удалим все *.dmp файлы.
4. Обновление: По возможности перейдем на стабильную версию платформы (например, 8.3.25.1546 или выше), где исправлены ошибки утечки памяти и зацикливания ППД.
5. Оптимизация ЖР: Переведем журнал регистрации в режим записи только ошибок в базах ЗУП и БУХ.
6. Общее обслуживание: Чтобы снизить общую нагрузку на дисковую подсистему, полезно регулярно выполнять удаление помеченных на удаление объектов и проводить универсальное сжатие базы за счет очистки старых данных.

Следуя этим шагам, мы не только вернем свободное место на диске, но и значительно повысим стабильность работы всего серверного кластера 1С.