Чистим кэш 1С на сервере, когда пользователи ловят зависания

Чаще всего «чистку кэша на сервере» начинают с удаления всего подряд в каталоге srvinfo. Это ошибка: там лежит реестр кластера, и без него информационные базы просто не откроются. Чистить нужно только то, что действительно является кэшем: временные файлы пользователей, служебные каталоги сеансов snccntx* и временные данные СУБД.

Кэш пользователя 1С на сервере — это файлы в профиле пользователя на терминальном сервере (каталоги 1Cv8 в Local и Roaming), временные каталоги процессов rphost и каталоги сеансов в кластере. Ниже — порядок действий от безопасного к радикальному. Без «чистки всего» и без полётов вслепую.

Как понять, что кэш на сервере действительно переполнен

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

Типичные признаки:

• 🐌 пользователи терминального сервера жалуются, что 1С «думает» при открытии форм, а в других программах тормозов нет;
• 💾 системный диск почти заполнен, хотя базы лежат на другом томе;
• 🔁 после перезапуска сеанса работа на время нормализуется;
• ⚠️ в журнале Windows появляются сообщения о нехватке места, а у пользователей — ошибки при формировании отчётов.

Проверьте, что именно занимает место. На Windows откройте свойства каталогов или воспользуйтесь любой утилитой анализа дисков (WinDirStat, TreeSize). Смотрите на четыре места:

Папки в профиле пользователя имеют имена-идентификаторы (длинные GUID). Размер одной такой папки в десятки и сотни мегабайт — норма для крупной конфигурации. Тревожный сигнал — десятки гигабайт на одного пользователя или тысячи каталогов snccntx* в кластере.

Быстрая проверка до остановки служб

Посмотрите список сеансов в консоли администрирования кластера (оснастка «Администрирование серверов 1С Предприятия»). Если сеансов сотни, а пользователей десятки, значит, остались «зависшие» сеансы — они держат файлы и не дают очистить каталоги.

Через командную строку то же самое делает утилита rac:

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

Идентификатор кластера покажет команда rac cluster list.

Подготовка сервера: что сделать до удаления файлов

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

1. Назначьте окно работ: вечер или выходные, когда в базах никто не работает . Предупредите пользователей заранее.
2. Убедитесь, что есть свежие резервные копии баз и каталога кластера. Для файловой копии кластера остановите службу (это следующий шаг), а для баз на СУБД — используйте штатное резервное копирование .
3. Запишите текущие настройки: имя службы агента сервера, порт кластера, учётную запись, от имени которой она запущена. После запуска вы сверите всё это.
4. Переименуйте, а не удаляйте. Каталоги, в которых не уверены, лучше переименовать (добавить к имени _old). Если всё работает, удалите позже.

Перед работой с каталогом кластера сделайте копию srvinfo целиком. Без неё восстановить список баз и настройки кластера не получится.

Останавливаем службу сервера 1С и завершаем зависшие процессы

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

Если нужна чистка каталогов кластера, остановите службу целиком.

Windows

Имя службы у разных версий отличается, поэтому сначала найдите точное имя:

sc query state= all | findstr /i "1C:Enterprise"

Затем остановите агент сервера, подставив своё имя:

net stop "1C:Enterprise 8.3 Server Agent (x86-64)"

Служба ragent при остановке завершает дочерние процессы rmngr и rphost. Но иногда процесс остаётся в памяти. Проверьте:

tasklist | findstr /i "ragent rmngr rphost 1cv8"

Если процессы остались, завершите их вручную в «Диспетчере задач» или командой taskkill /F /IM rphost.exe. Принудительное завершение — крайняя мера, применяйте её только после остановки службы.

Linux

sudo systemctl stop srv1cv83
ps aux | grep -E "ragent|rmngr|rphost"

Имя юнита зависит от версии платформы и способа установки. Если systemctl не находит srv1cv83, посмотрите список: systemctl list-units | grep 1c.

Клиентские процессы на терминальном сервере

Если вы чистите профили пользователей, нужно, чтобы не работали и клиентские процессы 1cv8.exe, 1cv8c.exe. Завершите сеансы пользователей в «Диспетчере служб терминалов» или попросите выйти.

Ручное удаление кэша через файловую систему

Службы остановлены. Теперь по порядку, от безопасного.

Шаг 1. Временные файлы

Очистите %TEMP% пользователя и системный каталог временных файлов. Удалять можно всё, что не занято. Занятые файлы Windows пропустит сама.

Шаг 2. Кэш в профиле пользователя

Для конкретного пользователя удалите содержимое каталогов:

• C:\Users\<имя>\AppData\Local\1C\1Cv8\<GUID>
• C:\Users\<имя>\AppData\Roaming\1C\1Cv8\<GUID>

Нужную папку можно определить по дате изменения и размеру. Если не уверены в соответствии GUID и базы, очистите все — платформа создаст их заново при следующем входе.

Не удаляйте файл ibases.v8i и каталог 1CEStart, если не хотите, чтобы у пользователя пропал список баз. Он лежит в Roaming\1C\1CEStart.

Цена очистки кэша конфигурации — первый запуск базы после неё будет дольше: платформа заново получит конфигурацию с сервера. Для крупной типовой конфигурации это от нескольких секунд до минуты.

Шаг 3. Каталоги сеансов в кластере

В srvinfo\reg_1541\<GUID базы> лежат каталоги snccntx<число>. Это служебные данные сеансов. Если службы остановлены, их можно удалять.

Порядок:

1. Откройте srvinfo\reg_1541 и найдите каталог с нужным GUID базы.
2. Внутри уберите папки snccntx*.
3. Файлы 1CV8Clst.lst и подкаталоги реестра не трогайте.

Если всё это нужно только для одного пользователя

Для сервера терминалов бывает достаточно удалить профиль одного пользователя или его каталоги 1C в AppData. Остальные пользователи ничего не заметят. Это самый щадящий путь, поэтому начните с него.

Сравнение способов

Временные данные в СУБД: что чистить и чего не трогать

Если базы лежат на SQL Server или PostgreSQL, часть «кэша» живёт там. Но здесь нужна осторожность: таблицы самой информационной базы вручную очищать нельзя. Их структура известна только платформе, и ручное удаление приведёт к повреждению базы.

Что допустимо:

• Microsoft SQL Server. База tempdb хранит временные таблицы, которые платформа создаёт при работе запросов. После перезапуска службы SQL Server она пересоздаётся пустой. Если tempdb раздулась до десятков гигабайт, плановый перезапуск службы решает вопрос. Заодно проверьте, нет ли «долгих» транзакций, которые держат её.
• PostgreSQL. Временные таблицы существуют только в рамках соединения и удаляются при его закрытии. Завершите зависшие подключения, и место освободится. Для освобождения места после массового удаления данных применяют VACUUM, а для возврата места ОС — VACUUM FULL (он блокирует таблицу, делайте его в окно работ).
• Журнал транзакций SQL Server. Если он растёт, проверьте модель восстановления и расписание резервного копирования журнала. Это обслуживание СУБД, а не очистка кэша 1С.

Для PostgreSQL посмотреть, кто держит соединения, можно запросом:

SELECT pid, usename, datname, state, query_start
FROM pg_stat_activity
WHERE datname = 'имя_базы';

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

Для тех, кто хочет «почистить таблицы 1С» вручную: единственное безопасное обслуживание таблиц самой базы — штатные средства 1С: «Тестирование и исправление» и регламентные операции СУБД (обновление статистики, реиндексация). Это не очистка в прямом смысле, но оно устраняет типичные причины торможения.

Запуск служб и проверка работоспособности

Когда файлы убраны, запустите службу.

net start "1C:Enterprise 8.3 Server Agent (x86-64)"

На Linux: sudo systemctl start srv1cv83.

Что проверить сразу:

1. В консоли кластера кластер и сервер рабочих процессов в списке, базы на месте.
2. Подключитесь к базе от тестового пользователя. Первый вход будет медленнее — кэш строится заново.
3. Откройте тяжёлый отчёт, который раньше тормозил, и сравните время.
4. Посмотрите журнал Windows и журнал сервера на ошибки службы.
5. Через 15–20 минут проверьте число сеансов и размер каталога snccntx*: если растёт быстрее прежнего, дело не в кэше.

Профилактика: чтобы не чистить кэш каждую неделю

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

Ограничьте рост временных файлов

• Включите автоматическую очистку %TEMP% по расписанию (задача планировщика, которая удаляет файлы старше 7 дней).
• Настройте политики терминального сервера: завершение отключённых сеансов через определённое время, например через 1–2 часа.
• Вынесите %TEMP% и профили на отдельный том, чтобы переполнение не останавливало систему.

Автоматизируйте перезапуск

Многие администраторы настраивают плановый перезапуск рабочих процессов кластера в консоли: у кластера есть параметры «Интервал перезапуска» и «Допустимый объём памяти». Типичная настройка — перезапуск рабочих процессов раз в сутки ночью. Подробные значения подбирайте под свою нагрузку: слишком частые перезапуски мешают пользователям.

Минимальный скрипт очистки временных файлов для планировщика:

forfiles /p "C:\Windows\Temp" /s /m *.* /d -7 /c "cmd /c del /q /f @path"

Он удаляет файлы старше семи дней. Проверьте его на тестовом каталоге перед боевым запуском.

Вопросы к самой конфигурации

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

Когда чистить не нужно

Не нужно чистить кэш, если тормозит только одна база, а временных файлов мало. Не нужно, если ошибка воспроизводится на всех компьютерах, а на сервере всё в порядке. И не нужно «на всякий случай» — на каждую очистку приходится первый медленный вход всех пользователей.

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