В процессе эксплуатации высоконагруженных систем на платформе 1С:Предприятие 8.3 системные администраторы и разработчики часто сталкиваются с ситуацией, когда свободное место на диске сервера приложений начинает стремительно исчезать. Часто подозрение падает на Журнал регистрации, особенно если он вынесен на отдельный физический или логический диск. Однако, как показывает практика, истинная причина может скрываться глубже в структуре реестра кластера. В этой статье мы подробно разберем, почему происходят резкие «скачки» объема дискового пространства, как правильно диагностировать проблему и какие механизмы платформы за это отвечают.
Для начала разберем, что именно хранится в папке, которую мы обычно указываем при запуске службы сервера 1С с помощью параметра -d. Многие ошибочно полагают, что там находится только журнал регистрации, но это далеко не так. Внутри каталога srvinfo (или любого другого имени, заданного вами) располагаются папки с идентификаторами кластеров (например, reg_1541). Внутри этих папок находятся:
Проанализируем ситуацию: если вы зафиксировали резкий рост объема (например, на 25 ГБ) с последующим частичным возвратом места, крайне маловероятно, что это работа журнала регистрации. Журнал обычно растет линейно. Резкие скачки характерны для временных файлов или процессов индексации.
Как выяснилось в ходе обсуждения, наиболее частым виновником «взрывного» роста дискового пространства являются файлы полнотекстового поиска. Рассмотрим подробнее, как это работает. Индекс ППП состоит из основного индекса IndexMain и временного индекса IndexTemp.
Выясним причину резких скачков: при интенсивном изменении данных (массовое перепроведение документов, загрузка больших справочников) платформа активно пишет данные во временные файлы индекса. В определенный момент происходит процесс слияния (merge) временного индекса с основным. В этот момент системе требуется дополнительное место для формирования нового файла индекса, при этом старые файлы еще не удалены. Это и создает те самые скачки в десятки гигабайт.
Для решения проблемы с разросшимся индексом ППП проанализируем следующие шаги:
Indextemp и IndexMain. Если их суммарный объем критичен, необходимо принять меры.
// Очистка полнотекстового поиска
ПолнотекстовыйПоиск.Очистить();
// Запуск фонового обновления индекса
ПолнотекстовыйПоиск.Обновить(Истина, Ложь);
Если анализ папки ППП не дал результатов, рассмотрим по шагам работу с сеансовыми данными. Папка snccntx хранит временные данные, которые не поместились в оперативную память сервера. Рассмотрим подробнее сценарий: пользователь запускает крайне тяжелый отчет (например, ОСВ по всем счетам за 5 лет без отборов) или неоптимальный алгоритм создает огромную временную таблицу. В этот момент rphost начинает сбрасывать «лишнее» на диск.
Посмотрим на поведение системы: как только отчет сформирован или пользователь закрыл сеанс (или сеанс «вылетел» по ошибке), эти временные файлы удаляются. Это идеально объясняет «откат» размера диска к исходному значению после резкого прыжка. Чтобы локализовать проблему, рекомендуем использовать мониторинг (например, Zabbix или встроенный PerfMon), настроенный на отслеживание размера конкретных подпапок в реальном времени.
Разберем техническую сторону переноса данных. Существует несколько способов переместить srvinfo или его части:
Это самый надежный метод. В строке запуска службы 1C:Enterprise 8.3 Server Agent мы указываем ключ -d "D:\YourFolder". Важно понимать, что при этом переносится весь реестр кластера со всеми индексами и журналами. Рассмотрим пример правильной настройки:
"C:\Program Files\1cv8\8.3.22.1709\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "D:\srvinfo"
Системные администраторы иногда пытаются использовать Hardlinks или Junction points для выноса только папки 1Cv8Log. Проанализируем риски: платформа 1С при обновлении или определенных операциях обслуживания может пытаться переименовывать или удалять папки. Использование mklink в среде Windows для рабочих папок 1С часто приводит к нестабильной работе и ошибкам доступа («Ошибка работы с файлом»). Мы рекомендуем избегать этого метода в пользу штатных средств платформы.
В современных версиях платформы реализована возможность указать местоположение журнала регистрации отдельно. Это делается через файл conf.cfg или настройки конкретной информационной базы. Это наиболее грамотный подход, если ваша цель — разнести именно логи и данные индексов по разным физическим дискам для повышения производительности.
Чтобы избежать внезапных остановок работы пользователей из-за нехватки места, разберем комплекс превентивных мер:
1Cv8FTxt и snccntx. Это поможет выявить «виновного» пользователя или отчет до того, как база упадет.Подведем итог: если вы видите скачкообразный рост места на диске сервера 1С, первым делом проверьте настройки полнотекстового поиска и наличие тяжелых пользовательских запросов, забивающих сеансовые данные. Правильная настройка регламентных заданий и регулярный мониторинг — залог стабильной работы системы.