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

Серверный кэш 1С чистят одним способом: останавливают сеансы нужной базы, затем удаляют служебные каталоги snccntx* в папке данных кластера и временные файлы пользователя службы. Утилита rac сама кэш не стирает, она только завершает сеансы. Каталог srvinfo целиком удалять нельзя: внутри лежит реестр кластера.

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

Что лежит на сервере и что здесь называют кэшем

«Кэш» на сервере 1С — не один каталог, а три разных места. Путать их опасно: удалишь не то, и кластер перестанет подниматься.

Порт 1541 — стандартный порт менеджера кластера. Если вы меняли порт при установке, имя каталога будет другим: reg_ и номер вашего порта.

Расположение srvinfo задаётся при установке службы агента. Посмотрите его в свойствах службы «Агент сервера 1С:Предприятия 8.3» на Windows: путь указан в параметре -d в строке запуска. На Linux каталог по умолчанию лежит в домашней папке пользователя usr1cv8.

Откуда берётся мусор

• 🗂 Серверные контексты накапливаются: каждый сеанс оставляет свой каталог, и после аварийных обрывов часть из них не убирается.
• 📦 Временные файлы рабочих процессов копятся при выгрузках, загрузках, печати больших форм.
• 🧾 Журналы технологического журнала, если вы его включали и забыли выключить. Они растут быстрее всего.

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

Признаки того, что чистка действительно нужна

Не надо чистить «на всякий случай» по расписанию каждый день. Холодный старт после очистки медленный: серверу заново строить контексты, а пользователи первые минуты видят замедление.

Чистите, когда видите конкретное:

• 🐢 база стала открываться заметно дольше, хотя нагрузка прежняя;
• ❌ после обновления конфигурации или платформы появляются ошибки на устаревшие метаданные, а перезапуск клиента не помогает;
• 💾 на диске с srvinfo осталось меньше 10-15% свободного места;
• 🔁 в списке сеансов висят «мёртвые» соединения, которых нет у пользователей.

Подготовка и диагностика перед удалением

Сначала выясните, что и где занимает место. На Windows откройте каталог данных кластера и отсортируйте вложенные папки по размеру. В PowerShell тот же результат даёт команда:

Get-ChildItem "D:\srvinfo\reg_1541" -Directory |
  ForEach-Object { [pscustomobject]@{ Name=$_.Name; MB=[math]::Round((Get-ChildItem $_.FullName -Recurse -File -ErrorAction SilentlyContinue | Measure-Object Length -Sum).Sum/1MB) } } |
  Sort-Object MB -Descending

Путь D:\srvinfo замените на свой. Каталоги с именем-идентификатором — это информационные базы (внутри может лежать их собственный реестр). Каталоги snccntx* — серверные контексты.

На Linux хватит стандартных утилит:

du -sh /home/usr1cv8/.1cv8/1C/1cv8/reg_1541/* | sort -h | tail -20

Резервная копия

Саму базу копируйте отдельно: выгрузкой в .dt из конфигуратора либо средствами СУБД. Копия srvinfo базу не заменяет.

Узнайте идентификатор нужной базы

Если у вас несколько баз, нужно понять, какой каталог чей. Идентификатор информационной базы выдаёт rac (см. следующий раздел), а в консоли администрирования серверов он показан в свойствах базы. Не гадайте по датам изменения файлов.

Завершение сеансов через rac

rac — консольный клиент администрирования. Он идёт в комплекте с сервером 1С в каталоге bin платформы. Работает в связке со службой ras: сначала её нужно запустить.

ras cluster --port=1545

Порт по умолчанию — 1545, это порт ras, а не рабочий порт кластера. После запуска в другом окне работайте с rac.

Шаг 1. Найти кластер

rac cluster list

Команда выведет идентификатор кластера (cluster), имя и порт. Идентификатор нужен во всех следующих командах.

Шаг 2. Найти базу

rac infobase summary list --cluster=<идентификатор кластера>

Из вывода берёте поле infobase, это идентификатор базы, и name, имя.

Шаг 3. Посмотреть и завершить сеансы

rac session list --cluster=<кластер> --infobase=<база>
rac session terminate --cluster=<кластер> --session=<идентификатор сеанса>

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

Шаг 4. Закрыть вход в базу на время работ

Чтобы пользователи не зашли обратно, запретите подключения на время чистки. Это делается в консоли администрирования в свойствах информационной базы (блокировка начала сеансов) или параметрами rac infobase update. Точные имена параметров смотрите в справке rac infobase update --help для вашей версии платформы: они менялись от релиза к релизу, и выдумывать их по памяти не стоит.

Удаление серверных контекстов snccntx

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

Windows

1. Откройте оснастку «Службы» и остановите «Агент сервера 1С:Предприятия 8.3». Если на сервере работает ещё и ras, остановите его тоже.
2. Убедитесь, что процессов ragent, rmngr, rphost в диспетчере задач нет. Зависшие завершите вручную.
3. Откройте reg_1541 в каталоге srvinfo.
4. Удалите только каталоги snccntx*. Не трогайте файлы 1CV8Clst.lst и каталоги с идентификаторами баз.
5. Запустите службу агента и подождите минуту-две, пока поднимутся процессы.

Linux

systemctl stop srv1cv83
find /home/usr1cv8/.1cv8/1C/1cv8/reg_1541 -maxdepth 1 -type d -name 'snccntx*' -exec rm -rf {} +
systemctl start srv1cv83

Имя юнита srv1cv83 зависит от установки, проверьте через systemctl list-units | grep 1c. Путь и номер порта тоже подставьте свои.

Если вы не уверены, какой каталог перед вами, не удаляйте его. Переименуйте в .bak и запустите службу: исчезнет проблема — удалите потом, возникнет ошибка — вернёте имя.

Что произойдёт после запуска

Первый вход пользователей будет медленнее обычного. Сервер заново строит контексты, прогревает кэш метаданных и компилирует серверные модули. Предупредите сотрудников: минуты три-пять база «раскачивается», это нормально.

Временные файлы системы и пользователя службы

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

Windows

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

• C:\Users\<пользователь службы>\AppData\Local\Temp
• C:\Windows\Temp, если служба работает от системной учётной записи

Остановите службу и очистите содержимое папок, оставив сами каталоги. Файлы, которые заняты, пропустите.

Заодно проверьте клиентский кэш, если на сервере что-то запускается клиентом (терминальный сервер , веб-клиент через сервер приложений). Он лежит в %LOCALAPPDATA%\1C\1cv8 и %APPDATA%\1C\1cv8 пользователя. Для терминального сервера это самая частая причина «после обновления глючит у всех».

Клиентский кэш можно сбросить и без ручного удаления, ключом запуска /ClearCache при старте 1cv8.exe.

Linux

find /tmp -maxdepth 1 -user usr1cv8 -mtime +1 -exec rm -rf {} +

Фильтр -mtime +1 оставит свежие файлы, которые могут быть нужны работающим процессам. Запускайте при остановленной службе или хотя бы убедитесь, что регламентные задания не идут.

Технологический журнал

Если он включён, проверьте его каталог и размер. Журнал не кэш, но именно он чаще всего забивает диск. Выключить его можно, удалив или переименовав файл logcfg.xml в каталоге conf платформы. Старые файлы журнала удаляйте после того, как расследование закончено.

Автоматическая чистка по расписанию и про RLS

Иногда в таких инструкциях вспоминают RLS. Уточним, чтобы не терять время: RLS в 1С — ограничение доступа на уровне записей, то есть права пользователей. К очистке кэша она отношения не имеет, и отдельного «параметра RLS для автоочистки» нет.

Автоматизируется всё обычным планировщиком: Task Scheduler на Windows или cron на Linux. Схема одна:

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

Для Linux пример для cron в ночь на воскресенье:

0 3 * * 0 /usr/local/bin/clean1c.sh >> /var/log/clean1c.log 2>&1

Тело скрипта clean1c.sh собирается из команд раздела выше. Перед включением прогоните его вручную и проверьте, что служба поднимается.

Что сделать после очистки

Сама по себе очистка скорость не добавляет. Она убирает испорченное состояние. Чтобы эффект остался, проверьте остальное.

• ⚙️ Версии платформы. Клиент и сервер должны быть одной ветки. Разные версии дают лишнюю нагрузку и ошибки при подключении.
• 🗄 Обслуживание СУБД. Для PostgreSQL и MS SQL регулярно обновляйте статистику и перестраивайте индексы. Узкое место нередко именно там.
• 🧹 Регламентные задания. Слишком частые фоновые задания съедают процессы. Проверьте расписание в консоли администрирования.
• 📏 Рабочие процессы. Убедитесь, что память на сервере не исчерпана. Если rphost растёт без остановки, в кластере настраивают перезапуск процессов по таймеру или объёму памяти, значения подбирают под нагрузку.
• 🔎 Замеры. Откройте базу до и после чистки и засеките время запуска и проведения типового документа. Без замера непонятно, помогло ли.

Если после очистки стало хуже, откатитесь на копию srvinfo, остановив службу и вернув каталог на место.

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

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

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