Сброс серверного кэша 1С:Предприятия 8.3 в Windows и Linux

Чтобы очистить кэш базы 1С на сервере, остановите службу агента сервера 1С, удалите в каталоге кластера srvinfo\reg_1541 папки snccntx* и запустите службу снова. Файлы реестра кластера (1CV8Clst.lst) и папки баз с GUID в имени не трогайте. В Windows каталог по умолчанию — C:\Program Files\1cv8\srvinfo\reg_1541, в Linux — /home/usr1cv8/.1cv8/1C/1cv8/reg_1541.

Есть три уровня сброса. Ключ /ClearCache и чистка профиля пользователя убирают клиентский кэш — это быстро и никого не задевает. Удаление snccntx* сбрасывает серверный кэш сеансовых данных, но требует остановки службы. Перезапуск рабочих процессов без удаления файлов — промежуточный вариант, когда проблема в зависшем процессе, а не в данных на диске.

Когда серверный кэш 1С действительно пора чистить

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

Типичные симптомы, после которых имеет смысл сбросить кэш на сервере:

• 🔴 ошибки вида Сеанс отсутствует или удален у многих пользователей сразу;
• 🐢 база стала заметно медленнее открываться после сбоя питания или переполнения диска;
• 🔁 после обновления конфигурации часть пользователей видит старые формы и команды, хотя клиентский кэш у них уже очищен;
• 📁 папка reg_1541 разрослась до десятков гигабайт, а сервер не перезапускался месяцами;
• ⚙️ рабочий процесс rphost падает при входе в конкретную базу, а в другие базы того же кластера вход работает.

Если проблема у одного пользователя, начинайте не с сервера, а с его компьютера: запуск с параметром /ClearCache или удаление папок с GUID в %APPDATA%\1C\1cv8 и %LOCALAPPDATA%\1C\1cv8. Серверный сброс нужен, когда симптом массовый.

Где хранится кэш 1С на сервере в Windows и Linux

Каталог кластера задаётся параметром -d в командной строке службы агента. Поэтому надёжнее всего не угадывать путь, а посмотреть его в настройках службы.

Внутри каталога srvinfo лежит папка reg_1541 (число — порт менеджера кластера; если кластер на другом порту, будет reg_2541 и т. п.). Её содержимое:

В корне srvinfo есть ещё 1cv8wsrv.lst — список кластеров агента. Его тоже не удаляют.

Подготовка перед сбросом кэша на сервере

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

Что сделать заранее:

1. Выберите окно: ночь, выходной или обеденный перерыв, если кластер небольшой.
2. Предупредите пользователей и попросите закрыть 1С. В консоли администрирования кластера видно, кто сейчас работает.
3. Посмотрите, не идёт ли обмен, закрытие месяца или длительная выгрузка. Их лучше дождаться.
4. Скопируйте 1CV8Clst.lst и 1cv8wsrv.lst в отдельную папку вне srvinfo.
5. Проверьте место на диске: если оно кончилось, сначала разберитесь, чем занято, иначе проблема вернётся через неделю.

Кто сейчас в базе: проверка через rac

Если консоль администрирования не установлена, список сеансов можно получить из командной строки утилитой rac. Ей нужен запущенный сервер администрирования ras.

rac cluster list
rac session list --cluster=<id кластера>

Первая команда выводит идентификатор кластера, вторая — сеансы с именами пользователей, компьютерами и временем начала. Если параметры отличаются в вашей версии, сверьтесь со справкой rac help.

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

Очистка кэша 1С на сервере Windows вручную

Через оснастку служб

1. Откройте services.msc.
2. Найдите службу агента сервера 1С:Предприятия 8.3. Отображаемое имя начинается с 1C:Enterprise 8.3 Server Agent.
3. Остановите службу и дождитесь, пока в «Диспетчере задач» исчезнут процессы ragent.exe, rmngr.exe и rphost.exe.
4. Откройте каталог srvinfo\reg_1541 по пути из параметра -d.
5. Удалите все папки, чьё имя начинается с snccntx.
6. Запустите службу.

Если какой-то файл не удаляется с сообщением «файл занят другим процессом», значит, один из процессов кластера ещё жив. Завершите оставшийся rphost.exe вручную или подождите минуту и повторите.

Через PowerShell

Те же действия одной командой, запускать от имени администратора:

$svc = Get-Service -DisplayName "1C:Enterprise 8.3 Server Agent*" | Select-Object -First 1
$reg = "C:\Program Files\1cv8\srvinfo\reg_1541"

Copy-Item "$reg\1CV8Clst.lst" "D:\backup_1c\1CV8Clst_$(Get-Date -Format yyyyMMdd_HHmm).lst"
Stop-Service -Name $svc.Name -Force
Start-Sleep -Seconds 15
Get-ChildItem $reg -Directory -Filter "snccntx*" | Remove-Item -Recurse -Force
Start-Service -Name $svc.Name

Путь в $reg поменяйте на свой, если каталог кластера перенесён на другой диск. Папку D:\backup_1c создайте заранее.

Как сбросить кэш 1С на сервере Linux (Ubuntu, CentOS)

На Linux сервер 1С работает от пользователя usr1cv8, и все файлы кластера принадлежат ему. Порядок тот же: остановить службу, удалить snccntx*, запустить.

Остановка службы

Имя службы зависит от способа установки и версии платформы:

• в старых установках — init-скрипт srv1cv83;
• в новых сборках платформы — юнит systemd, имя которого содержит номер версии.

Точное имя найдите командой:

systemctl list-units --type=service | grep -i 1c

Удаление кэша

SVC="srv1cv83"                         # подставьте имя из вывода systemctl
REG="/home/usr1cv8/.1cv8/1C/1cv8/reg_1541"

sudo cp "$REG/1CV8Clst.lst" "/root/1CV8Clst_$(date +%Y%m%d_%H%M).lst"
sudo systemctl stop "$SVC"
sleep 15
pgrep -u usr1cv8 -l                    # список должен быть пустым
sudo rm -rf "$REG"/snccntx*
sudo systemctl start "$SVC"

Если pgrep что-то показал, процессы не завершились. Подождите ещё немного; принудительное kill используйте только когда уверены, что все пользователи вышли.

После удаления проверьте владельца каталога: ls -la "$REG". Если вы случайно создали там файлы от root (например, распаковали архив), верните права:

sudo chown -R usr1cv8:grp1cv8 /home/usr1cv8/.1cv8

Автоматизация очистки кэша скриптами по расписанию

Регулярная чистка оправдана, если кластер работает без перезагрузок месяцами и reg_1541 заметно растёт. Для небольших серверов, которые перезагружаются при каждом обновлении Windows, плановый сброс обычно не нужен.

Windows: Планировщик заданий

1. Сохраните скрипт из раздела про Windows в файл, например C:\scripts\clear_1c_cache.ps1, и добавьте в него запись в лог.
2. В «Планировщике заданий» создайте задачу с запуском от имени SYSTEM или администратора, с флагом «Выполнить с наивысшими правами».
3. Действие: программа powershell.exe, аргументы -ExecutionPolicy Bypass -File C:\scripts\clear_1c_cache.ps1.
4. Триггер: раз в неделю, например в воскресенье в 04:00.

Linux: cron

Сохраните bash-скрипт в /usr/local/bin/clear_1c_cache.sh, выдайте права chmod 700 и добавьте строку в crontab -e пользователя root:

0 4 * * 0 /usr/local/bin/clear_1c_cache.sh >> /var/log/clear_1c_cache.log 2>&1

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

Проверка и диагностика проблем после очистки кэша

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

Быстрая проверка, что всё в порядке:

• ✅ служба запущена, в списке процессов есть ragent, rmngr, rphost;
• ✅ в консоли администрирования видны все базы кластера;
• ✅ в reg_1541 появились новые папки snccntx* — сервер их создал заново;
• ✅ тестовый пользователь входит в базу и проводит документ без ошибок.

Если очистка кэша не помогла

Есть ещё несколько шагов, которые решают похожие симптомы и при этом не требуют сносить что-либо на сервере:

1. Перезапуск рабочих процессов. В свойствах рабочего сервера можно задать ограничение по памяти и интервал перезапуска rphost. Это снижает потребность в ручных сбросах.
2. Клиентский кэш у всех пользователей. Если после обновления конфигурации интерфейс «старый», почистите %APPDATA%\1C\1cv8 и %LOCALAPPDATA%\1C\1cv8 в профилях или раздайте ярлык с /ClearCache.
3. Тестирование и исправление базы. Проверка логической и ссылочной целостности в Конфигураторе. Перед ней — резервная копия.
4. Проверка СУБД. Обслуживание индексов и статистики в PostgreSQL или MS SQL часто убирает «тормоза», которые списывают на кэш.

Частые вопросы про кэш сервера 1С