Очистка кэша кластера 1С: что удалять, чем и в каком порядке

Пользователи жалуются, что 1С «задумывается» на каждом проведении, а на сервере в каталоге кластера выросли сотни мелких файлов. Чтобы удалить кэш сервера 1С, остановите службу агента сервера, очистите папки snccntx* внутри каталога reg_1541 и запустите службу заново. Утилита RAC эту работу целиком не делает, она лишь завершает сессии и помогает подготовить сервер.

Кэш сервера 1С копится в рабочих каталогах кластера, а не в самой базе. Поэтому очистка не затрагивает данные. Но порядок действий важен: удаление файлов под работающим кластером даёт сбои и «зависшие» сессии.

Откуда берётся мусор и когда его пора чистить

Серверный кэш состоит из служебных файлов, которые кластер создаёт для сеансов, блокировок и данных контекста. Часть из них должна удаляться сама при завершении сеанса. Если сеанс оборвался аварийно, файлы остаются.

Что обычно раздувает каталог:

• 🔸 аварийное завершение рабочих процессов rphost (нехватка памяти, убитый процесс);
• 🔸 обрывы связи с клиентами: сессия числится в кластере, а пользователя давно нет;
• 🔸 обновление платформы или конфигурации на «живом» сервере;
• 🔸 регламентные задания, которые запускаются и не закрываются;
• 🔸 включённый технологический журнал без ограничения по сроку хранения.

Признаки, что пора чистить:

Подготовка: резервная копия и список сеансов

Перед удалением сделайте три вещи.

1. Сохраните копию каталога кластера. Если места мало, достаточно скопировать файл 1CV8Clst.lst и список баз: так вы сможете восстановить регистрацию кластера при ошибке.
2. Выгрузите базу в .dt или снимите копию средствами СУБД. Кэш на данные не влияет, но работа на сервере всегда должна иметь точку возврата.
3. Предупредите пользователей: через RAC или консоль администрирования их сеансы будут завершены.

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

Очистка через RAC и ras: завершаем сеансы, а не файлы

RAC (rac.exe) работает как клиент к серверу администрирования ras. Сначала поднимите ras, затем обращайтесь к нему.

Запуск сервера администрирования (порт по умолчанию 1545):

ras.exe cluster --port=1545 localhost:1540

Здесь 1540 — порт агента сервера. Запрос списка кластеров:

rac.exe localhost:1545 cluster list

В ответе нужен идентификатор кластера (cluster). Дальше все команды привязываются к нему.

Список и завершение сеансов

Посмотреть сеансы :

rac.exe localhost:1545 session list --cluster=<идентификатор_кластера>

Завершить один сеанс:

rac.exe localhost:1545 session terminate --session=<идентификатор_сеанса> --cluster=<идентификатор_кластера>

Если кластер защищён паролем администратора, добавьте параметры --cluster-user и --cluster-pwd.

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

rac.exe localhost:1545 infobase summary list --cluster=<идентификатор_кластера>

Затем отфильтруйте список сеансов по полю infobase в выводе. Скриптом это делается несколькими строками на PowerShell или bash: читаете вывод, берёте строки session, для каждой вызываете terminate.

Что RAC не умеет

Прямой команды «очистить кэш » у RAC нет. Он управляет кластером: сеансами, соединениями, рабочими серверами, блокировками. Файлы на диске остаются.

Поэтому схема такая: через RAC завершили сеансы и соединения, остановили службу, удалили файлы вручную. Если вам где-то предлагают единственную команду RAC «для очистки кэша», проверьте её по справке: rac.exe help показывает реальный набор режимов.

Ручное удаление: пошаговая процедура

Это основной способ, когда сеансы уже мёртвые, а файлы остались.

Шаг 1. Завершите сеансы и остановите службу

1. Завершите пользовательские сеансы через RAC или консоль кластера.
2. Остановите службу «Агент сервера 1С:Предприятия 8.3» (в Windows через services.msc, в Linux через systemctl stop).
3. Убедитесь, что процессов ragent, rmngr, rphost в списке нет. Остались — завершите принудительно.

Шаг 2. Найдите каталог кластера

Путь зависит от параметра -d службы. Типичные места:

• Windows: C:\Program Files\1cv8\srvinfo\reg_1541
• Linux: /home/usr1cv8/.1cv8/1C/1cv8/reg_1541

Цифры 1541 — порт менеджера кластера. Если вы меняли порт, папка называется иначе: reg_ и ваш номер. Внутри лежат папки с именами-идентификаторами баз и файлы snccntx*.

Шаг 3. Удалите временные данные

Удаляйте только то, что относится к кэшу сеансов:

• файлы и папки snccntx* внутри каталогов баз;
• устаревшие подкаталоги сеансов, если они остались от оборванных соединений.

Не трогайте 1CV8Clst.lst, файлы 1cv8wsrv.lst и папки с идентификаторами баз целиком. В них хранится регистрация кластера и баз.

Для Windows удобен такой вариант в PowerShell (путь поправьте под себя):

Get-ChildItem "C:\Program Files\1cv8\srvinfo\reg_1541" -Recurse -Filter "snccntx*" |
  Remove-Item -Recurse -Force

Для Linux:

find /home/usr1cv8/.1cv8/1C/1cv8/reg_1541 -name 'snccntx*' -exec rm -rf {} +

Шаг 4. Запустите службу и проверьте

Запустите агент сервера, откройте базу тестовым пользователем и проведите любой документ. Первый вход после очистки может быть чуть медленнее: кластер заново собирает контекст. Дальше скорость выравнивается.

Если не помогло

Бывает, что после очистки легче не стало. Тогда причина не в файлах:

1. Проверьте размер самой базы и фрагментацию индексов в СУБД: на SQL Server помогает плановое обслуживание индексов и статистики.
2. Посмотрите нагрузку: один тяжёлый регламентный отчёт способен занять rphost целиком.
3. Сравните версии платформы на клиенте и на сервере. Рассогласование даёт лишние перезапуски сеансов.
4. Очистите ещё и клиентский кэш: параметр запуска /ClearCache для 1cv8.exe или удаление каталога базы в %LOCALAPPDATA%\1C\1cv8 и %APPDATA%\1C\1cv8.

Какой способ выбрать

Способы не взаимозаменяемы, у каждого своя задача.

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

Как понять, что кэш виноват

Сделайте простую проверку. Откройте ту же базу с другого компьютера под тем же пользователем. Если там быстро, проблема локальная, и серверный кэш ни при чём. Если медленно везде и в журналах видны оборванные сеансы, дело в кластере.

Ещё один ориентир: засеките время открытия тяжёлого отчёта до и после очистки. Выигрыш в десятки процентов говорит о том, что мусор мешал. Если время не изменилось, ищите причину в запросах, блокировках или СУБД, а чистку больше не повторяйте.

Автоматическая очистка и лимиты

Ручная очистка помогает разово. Чтобы мусор не копился, настройте профилактику.

Перезапуск рабочих процессов

В свойствах кластера (консоль администрирования серверов 1С) есть параметры рабочих серверов и процессов:

• интервал перезапуска рабочих процессов: типовое значение для нагруженной базы 86400 секунд, то есть раз в сутки;
• допустимый объём памяти процесса: при превышении процесс завершается и создаётся заново;
• время ожидания на завершение: сколько процесс дорабатывает перед принудительной остановкой.

Не ставьте перезапуск слишком часто. Раз в час превратит работу в постоянные переподключения. Разумный старт: ночное окно при минимальной нагрузке.

Плановое задание

Скрипт ночной чистки состоит из тех же шагов, что и ручная процедура:

1. Через RAC завершить сеансы выбранных баз.
2. Остановить службу.
3. Удалить snccntx* и старые файлы журналов.
4. Запустить службу.

В Windows это задача планировщика, в Linux таймер systemd или cron. Пишите результат в лог: утром вы увидите, сколько файлов и мегабайт удалено.

Хранение журналов

Журналы технологического журнала задаются файлом logcfg.xml в каталоге conf платформы. Там же настраивается срок хранения: например, history="24" часа, чтобы журнал не рос неделями. Если журнал включали «на разок» и забыли, он и будет главным пожирателем диска.

Диагностика: что показывают логи

Прежде чем что-то удалять, посмотрите, что именно растёт.

Порядок такой:

1. Выясните размер каталогов по убыванию. Если вырос журнал, а не snccntx*, чистить кэш бессмысленно.
2. В технологическом журнале найдите события EXCP: частое повторение одного исключения указывает на источник сбоев.
3. Сопоставьте время сбоев с расписанием заданий и обновлениями.

Кластер из нескольких серверов

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

Что учесть:

• 🔹 чистите каждый рабочий сервер отдельно, останавливая на нём службу;
• 🔹 центральный сервер кластера хранит список баз и регистрацию, его каталог чистите осторожнее всего;
• 🔹 пока вы работаете с одним узлом, нагрузку примут остальные: проверьте, что запаса хватает;
• 🔹 последовательно, а не одновременно: оставьте в строю хотя бы один рабочий сервер, если пользователи должны продолжать работу.

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

Если сервер 1С и СУБД стоят на разных машинах, кэш 1С чистится только на стороне 1С. Кэш планов запросов SQL Server сбрасывать без нужды не следует: это ударит по производительности всей СУБД на время «прогрева».

Частые вопросы