Многие системные администраторы и разработчики 1С сталкиваются с ситуацией, когда свободное место на диске сервера начинает стремительно исчезать. Виновником оказывается папка srvinfo/Reg_1541, в которой файлы с непонятными именами (GUID) разрастаются до десятков и сотен гигабайт. Особенно часто эта проблема проявляется после обновления конфигураций (например, Розница 2.3 или УНФ) на платформе 8.3.
В этой статье мы подробно разберем, почему это происходит, как найти конкретную базу-виновника и какими способами можно навсегда остановить этот аномальный рост.
Для начала проанализируем, что именно хранится в директории C:/Program Files/1cv8/srvinfo/Reg_1541. Эта папка является "сердцем" кластера 1С. В ней находятся рабочие файлы информационных баз, сеансовые данные и индексы. Файлы и подпапки с длинными именами вида c5823d65-be9c-448b-a974-0891df205bb4 соответствуют внутренним идентификаторам (GUID) информационных баз.
Если на сервере опубликовано несколько баз, нам нужно понять, какая из них "съедает" диск. Для этого выполним следующие шаги:
Reg_1541.1cv8.lst.ID (GUID).Теперь, когда мы знаем, к какой базе относится раздувшийся файл, мы можем перейти к анализу причин.
Как показывает практика и обсуждения экспертов, в 99% случаев виновником является полнотекстовый поиск (ППД). Платформа 1С использует его для быстрого поиска данных по всем справочникам и документам. Однако в последних версиях платформы (особенно в ветках 8.3.22, 8.3.23 и ранних 8.3.24) этот механизм работает нестабильно.
Рассмотрим подробнее файл tablechanges.dat. Он предназначен для регистрации изменений в данных, которые должны быть проиндексированы. Из-за багов платформы (например, баг №10263300) система перестает очищать этот файл. Даже если данные уже проиндексированы, файл продолжает расти при каждой записи в базу данных. В некоторых случаях система может создавать огромные временные файлы индексов, которые не удаляются автоматически.
Если мы столкнулись с резким ростом файлов, первым делом попробуем стандартную процедуру обслуживания индекса. Это можно сделать непосредственно в пользовательском режиме 1С (если база запускается) или через консоль.
Разберем последовательность действий:
Важное замечание: Иногда процедуру очистки приходится выполнять несколько раз, так как с первого раза блокировки файлов могут помешать полному удалению.
Если полнотекстовый поиск не является критически важным для пользователей (а в "Рознице" его часто используют редко), лучше всего полностью отключить этот функционал. Это гарантированно остановит рост файлов.
Проанализируем шаги по отключению:
index внутри каталога с GUID нашей базы.Также важно зайти в консоль администрирования кластера и убедиться, что регламентные задания, связанные с полнотекстовым поиском (ОбновлениеИндексаППД и СлияниеИндексаППД), выключены.
Разработчики 1С признали наличие ошибки "бесконечного роста" файла tablechanges.dat. Начиная с версии платформы 8.3.24.1808 и в актуальных сборках 8.3.25, этот баг был исправлен. Если ваша версия платформы ниже, настоятельно рекомендуем запланировать обновление.
После обновления на исправленную версию платформы, система начнет корректно выполнять слияние фрагментов индекса и вовремя освобождать дисковое пространство. Рассмотрим, на какие версии стоит ориентироваться:
Выясним, что еще может провоцировать аномальное поведение сервера. Часто процесс rphost.exe не может корректно завершить запись в файлы индекса из-за внешних блокировок.
Антивирусное ПО: Обязательно добавим папку srvinfo в список исключений антивируса. Если антивирус решит проверить файл индекса в момент его слияния (merge), 1С может "потерять" дескриптор файла и начать писать данные в новый файл, не удалив старый. Это приводит к лавинообразному заполнению диска.
Бинарные данные: В конфигурации "Розница 2.3" после обновления могут запуститься процессы обработки картинок или сканов документов. Если эти данные хранятся прямо в базе данных, ППД пытается извлечь из них текст. При наличии поврежденных файлов индексатор может уйти в бесконечный цикл, создавая гигантские временные объекты в srvinfo.
Иногда раздуваются не индексы, а файлы в папке snccntx. Это сеансовые данные. Рассмотрим пример программной очистки или ограничения, если мы подозреваем утечку памяти в сеансах:
Системным администраторам рекомендуется настроить лимиты для процессов rphost в консоли администрирования кластера:
Это позволит серверу автоматически перезапускать "прожорливые" процессы, что косвенно поможет очистить временные файлы сеансовых данных.
Подведем итог. Чтобы победить "раздувание" файлов в Reg_1541, выполним следующие действия:
1cv8.lst.8.3.24.1808.Соблюдение этих правил позволит поддерживать стабильную работу сервера и избежать внезапных остановок из-за нехватки места на диске.