Очистка кэша сервера 1С:Предприятия: что удалять, а что трогать нельзя
Содержание
Кэш сервера 1С чистят остановкой службы сервера и удалением служебных папок сеансов snccntx* в каталоге кластера. Данные информационных баз при этом не затрагиваются: они лежат в СУБД, а кэш — это временные файлы, которые платформа соберёт заново.
Чистить стоит, когда сервер начал тормозить без видимой причины, в списке сеансов висят «зомби», а на диске с srvinfo растёт занятое место. Ниже — что именно лежит на сервере, как почистить кэш
вручную и автоматом, и как проверить, что после очистки всё поднялось.
Что и где кэшируется на сервере 1С
Путаница начинается с того, что «кэш 1С» — это три разные вещи. Чистят их по-разному.
| Что | Где лежит | Чем чистится |
|---|---|---|
| Клиентский кэш пользователя | %LOCALAPPDATA%\1C\1cv8 и %APPDATA%\1C\1cv8 на компьютере пользователя | Удалением папок с GUID или запуском с ключом /ClearCache |
| Кэш серверного кластера | Каталог кластера на сервере (по умолчанию srvinfo, внутри — папка вида reg_1541) | Остановкой службы и удалением snccntx* |
| Кэш СУБД | Память сервера PostgreSQL или SQL Server | Средствами СУБД, а не 1С |
Эта инструкция про второй пункт. Сервер хранит там реестр кластера, данные сеансов, журнал регистрации и служебные файлы. Не всё это можно удалять.
Что можно:
- 🗂 папки
snccntx*— серверный контекст сеансов (по одной на сеанс); - 🗂
*.tmpи остатки временных файлов в каталоге кластера; - 🗂 устаревшие дампы и архивы, которые кто-то сложил рядом с
srvinfo.
Что нельзя:
- ⛔ файл списка кластеров
1CV8Clst.lstи папки с GUID баз внутриreg_1541, пока вы не поняли, что в них; - ⛔ каталог журнала регистрации
1Cv8Log— это история действий пользователей, а не кэш; - ⛔ файлы баз
1Cv8.1CD, если у вас файловый вариант в том же каталоге.
Если вы не уверены, где какая папка, переименуйте её, а не удаляйте. Через день-два, когда убедитесь, что всё работает, сотрёте окончательно.
Как понять, что виноват именно серверный кэш
Не каждое торможение лечится чисткой. Перед остановкой службы проверьте признаки, чтобы не рвать сеансы зря.
- 📈 Каталог кластера вырос в разы за последние недели, а число баз и пользователей осталось прежним.
- 📈 В списке сеансов много записей от пользователей, которые давно ушли домой.
- 📈 После перезагрузки сервера всё работает быстро, а через несколько дней снова замедляется.
- 📈 В журнале событий службы встречаются сообщения об ошибках чтения или записи файлов сеансов.
Если нагрузка на процессор и диск у СУБД высокая, а каталог кластера невелик, причина в запросах, блокировках или настройках СУБД. Чистка кэша 1С там не поможет.
Стоит сравнить время открытия одного и того же отчёта на сервере и на тестовой копии базы. Разница в разы указывает на сервер приложений, а не на конфигурацию.
Подготовка: что сделать до очистки
Заранее нужно три вещи. На это уходит десять минут, зато откат будет простым.
- Выберите окно, когда в базах никто не работает . Для небольшой организации это вечер или раннее утро.
- Сделайте копию каталога кластера. Остановите службу (шаг ниже) и скопируйте
srvinfoцеликом на другой диск. - Узнайте, под какой учётной записью запущена служба сервера. Если после очистки у неё не будет прав на каталог, кластер не поднимется.
Перед любыми действиями с каталогом кластера нужна резервная копия. Выгрузка баз и копия srvinfo — минимум.
Если сеансов много, сначала выгоните пользователей штатно: через консоль серверов («Администрирование серверов 1С:Предприятия») откройте кластер, раздел сеансов, завершите нужные. То же можно сделать из командной строки — об этом дальше.
Ручная очистка папок кластера: шаг за шагом
Шаг 1. Остановите службу сервера
Откройте оснастку «Службы» и найдите службу агента сервера 1С:Предприятия. Название зависит от версии и разрядности платформы, ищите по слову «1C». Нажмите «Остановить». Дождитесь, пока статус сменится на «Остановлена», и проверьте в диспетчере задач, что процессов ragent, rmngr, rphost не осталось.
Если процессы висят, завершите их вручную. Только после этого переходите дальше.
Шаг 2. Найдите каталог кластера
Путь к нему указан в параметрах службы, в ключе -d. По умолчанию это srvinfo в каталоге установки платформы. Внутри лежит папка кластера: reg_ и номер порта менеджера кластера, обычно reg_1541.
Откройте её и отсортируйте содержимое по размеру. Обычно видно, куда ушло место.
Шаг 3. Удалите сеансовые данные
В папке кластера удалите все каталоги с именами snccntx и числовым суффиксом. Это серверный кэш сеансов.
rem Windows: удаление папок snccntx* (подставьте свой путь)
for /d %%D in ("D:\srvinfo\reg_1541\snccntx*") do rd /s /q "%%D"
Файлы журнала регистрации, списки баз и сами базы эта команда не заденет: маска жёстко ограничена именем.
Выполните сначала dir /ad "D:\srvinfo\reg_1541\snccntx*" и посмотрите, что попадёт под маску. Потом запускайте удаление.
Шаг 4. Запустите службу и проверьте
Запустите службу, подождите минуту-две и подключитесь к кластеру из консоли администрирования. Должен открыться список баз, а при входе в любую базу пересоздадутся свежие каталоги сеансов.
Первый вход после чистки идёт медленнее обычного: платформа заново строит кэш. Это нормально.
Если сервер на Linux
Логика та же, отличаются пути. Службу останавливают через systemctl (имя юнита зависит от версии платформы), а каталог кластера по умолчанию лежит в домашней папке пользователя usr1cv8. Удалять snccntx* нужно от этого же пользователя или с последующей правкой владельца файлов.
# проверьте, что попадает под маску, и только потом удаляйте
ls -d /home/usr1cv8/.1cv8/srvinfo/reg_1541/snccntx*
Очистка клиентского кэша на самом сервере
На терминальном сервере и на серверах, где пользователи запускают 1С прямо из сессии, кэш копится в профилях. Он не серверный, но часто именно он тормозит.
Есть два способа.
- Запуск клиента с параметром
/ClearCache. Он очищает кэш пользователя при старте, ничего не удаляя вручную. - Удаление папок с GUID в
%LOCALAPPDATA%\1C\1cv8и%APPDATA%\1C\1cv8.
Чтобы очистить кэш
у всех пользователей терминальной фермы, пройдитесь по профилям скриптом. Простой вариант для %LOCALAPPDATA%:
for /d %%P in ("C:\Users\*") do (
for /d %%D in ("%%P\AppData\Local\1C\1cv8\*-*") do rd /s /q "%%D"
)
Маска *-* ловит папки с GUID в имени. Файл 1cv8strt.pfl с настройками запуска и списком баз — не папка, он под маску не попадёт.
После чистки клиентского кэша у пользователей могут сброситься сохранённые настройки форм и «избранное» в интерфейсе. Предупредите людей заранее.
Управление сеансами через rac и ras
Утилита rac — клиент администрирования, ras — сервер, через который она подключается к кластеру. Кэш они напрямую не чистят. Зато с их помощью можно аккуратно выгнать зависшие сеансы и подготовить сервер к очистке, особенно когда консоль недоступна или серверов много.
Запуск ras (порт по умолчанию 1545):
ras cluster --port=1545 localhost:1540
Дальше в другом окне работаете через rac:
rem список кластеров — понадобится идентификатор
rac localhost:1545 cluster list
rem список сеансов выбранного кластера
rac localhost:1545 session list --cluster=<идентификатор кластера>
rem завершить конкретный сеанс
rac localhost:1545 session terminate --cluster=<идентификатор кластера> --session=<идентификатор сеанса>
Если на кластере заданы администраторы, добавьте параметры --cluster-user и --cluster-pwd. Порт менеджера кластера (здесь 1540) подставьте свой.
Список сеансов полезно сохранить в файл до чистки: rac ... session list > sessions_before.txt. Если что-то пойдёт не так, будет видно, кто работал.
Типичная схема для ночного обслуживания: запретить новые подключения к базе, завершить сеансы через rac, остановить службу, очистить каталоги, запустить службу, снять запрет. Все эти шаги скриптуются.
Автоматическая очистка по расписанию
Если сервер нагружен и кэш забивается каждые пару недель, чистить вручную надоедает. Планировщик заданий Windows закрывает вопрос.
Пример скрипта clear_cache.bat. Название службы и пути замените своими:
@echo off
set SVC="1C:Enterprise 8.3 Server Agent (x86-64)"
set CLUSTER=D:\srvinfo\reg_1541
net stop %SVC%
timeout /t 20 /nobreak >nul
for /d %%D in ("%CLUSTER%\snccntx*") do rd /s /q "%%D"
net start %SVC%
echo %date% %time% done >> D:\srvinfo\clear_cache.log
Как поставить на расписание:
- Откройте «Планировщик заданий» и создайте задачу (не «простую»: нужны расширенные параметры).
- На вкладке «Общие» выберите учётную запись с правами локального администратора и включите «Выполнять с наивысшими правами».
- На вкладке «Триггеры» задайте время вне рабочих часов. Раз в неделю — обычно достаточно.
- На вкладке «Действия» укажите путь к
clear_cache.bat. - Запустите задачу вручную один раз и проверьте лог.
Не ставьте чистку чаще раза в сутки. Каждая остановка службы рвёт все сеансы, а восстановление кэша нагружает сервер.
Если в ночное время работают регламентные задания или обмены, выберите окно между ними. Иначе остановка службы оборвёт обмен на середине.
Что проверить после очистки
Сразу после запуска службы пройдитесь по списку из четырёх пунктов.
- ✅ Кластер виден в консоли администрирования, все базы в списке.
- ✅ В нужную базу можно войти, формы открываются.
- ✅ Регламентные задания запускаются по расписанию (проверьте в консоли или в журнале регистрации).
- ✅ В журнале событий Windows нет ошибок службы 1С после запуска.
Как читать типичные проблемы:
srvinfo. Также проверьте права учётной записи службы на каталог.Профилактика: чтобы кэш не раздувался
Чистка лечит симптом. Причины стоит убрать.
- 🛡 Настройте перезапуск рабочих процессов в параметрах кластера: интервал перезапуска и допустимый объём памяти. Это снимает утечки в
rphost. - 🛡 Исключите каталог кластера и каталог временных файлов платформы из проверки антивирусом, если регламент безопасности это допускает.
- 🛡 Держите каталог кластера на быстром диске, отдельном от системного. SSD заметно снижает время «прогрева» после очистки.
- 🛡 Следите за свободным местом: когда осталось меньше 15-20%, диск работает хуже, и кэш становится проблемой.
- 🛡 Не оставляйте в кластере неиспользуемые базы и лишние сеансы пользователей, которые «забыли выйти».
- 🛡 Обновляйте платформу до актуальных релизов линейки 8.3: часть проблем с утечками исправляется в новых сборках.
Отдельно про журнал регистрации. Он не кэш, но разрастается быстрее всего. Если его формат старый (.lgf/.lgp), подумайте о переходе на формат SQLite, а для баз со старыми записями настройте регулярную чистку журнала средствами конфигуратора.
| Симптом | Что делать в первую очередь |
|---|---|
| Тормозит один пользователь | Чистить клиентский кэш на его компьютере |
| Тормозят все пользователи одной базы | Смотреть блокировки и нагрузку СУБД |
Тормозит весь сервер, растёт srvinfo | Чистить серверный кэш по этой инструкции |
Память rphost растёт сутками | Настроить перезапуск рабочих процессов |