Очистка серверного кэша 1С:Предприятия 8.3 без потери данных

Чтобы почистить кэш на сервере 1С, остановите службу «Агент сервера 1С:Предприятия 8.3», удалите в каталоге srvinfo\reg_1541 папки snccntx* и запустите службу снова. Всё. Файл 1CV8Clst.lst и папки с именами-GUID трогать не нужно.

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

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

Серверный кэш — это служебные данные, которые кластер хранит на диске и в памяти рабочих процессов: контексты сеансов, сведения о метаданных, временные файлы. Обычно они обновляются сами. Ломаются они после сбоев.

Чистить кэш имеет смысл в таких ситуациях:

• 🔄 после обновления конфигурации пользователи видят старые формы или получают ошибки, а в файловой копии той же базы всё работает;
• 💥 сервер аварийно перезагрузился или кончилось место на диске, и после этого сеансы падают с ошибками;
• 🐢 рабочие процессы rphost занимают всё больше памяти и не отпускают её даже ночью;
• ❌ появляются ошибки Ошибка формата потока, Неизвестная ошибка или разрыв соединения сразу после входа в базу;
• 🧩 конфигурацию обновили, а платформа продолжает считать, что структура не изменилась.

Если медленно работает один отчёт или один документ — кэш ни при чём. Это запрос, индексы или блокировки, и очистка не поможет.

Где хранится кэш сервера 1С и что в нём можно удалять

Все рабочие данные кластера лежат в каталоге srvinfo. Его расположение задаётся при установке сервера.

Если сервер ставили не по умолчанию, путь можно узнать из строки запуска службы. Откройте services.msc, найдите «Агент сервера 1С:Предприятия 8.3», в свойствах посмотрите «Исполняемый файл». Путь к каталогу идёт после ключа -d.

Внутри каталога вы увидите примерно такую картину:

Номер 1541 в имени папки — порт менеджера кластера. Если кластер работает на другом порту, папка называется иначе, например reg_2541.

Ручная очистка папок srvinfo на Windows-сервере

Это основной и самый надёжный способ. Он занимает 5–10 минут, но требует остановки сервера.

Все пользователи будут отключены от всех баз этого кластера. Несохранённые документы пропадут. Делайте это вечером или в выходной, предупредив людей заранее.

Шаг 1. Выгоните пользователей и закройте вход

1. Откройте консоль администрирования серверов 1С.
2. Для каждой базы в свойствах включите «Блокировка начала сеансов включена» и задайте сообщение для пользователей.
3. В разделе «Сеансы» убедитесь, что активных сеансов не осталось. Зависшие можно удалить из контекстного меню.

Шаг 2. Остановите службу агента

Откройте services.msc, найдите «Агент сервера 1С:Предприятия 8.3» и нажмите «Остановить». То же самое из командной строки администратора:

sc query state= all | findstr /I "1C:Enterprise"
net stop "1C:Enterprise 8.3 Server Agent (x86-64)"

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

После остановки проверьте в диспетчере задач, что процессов ragent.exe, rmngr.exe и rphost.exe больше нет. Если какой-то завис — подождите минуту и только потом завершайте вручную.

Шаг 3. Сделайте копию и удалите кэш

1. Скопируйте каталог srvinfo целиком в другое место. Это страховка на пять минут работы.
2. Зайдите в srvinfo\reg_1541.
3. Удалите все папки, имя которых начинается с snccntx.
4. Больше ничего в этом каталоге не удаляйте.

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

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

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

Снимите блокировку начала сеансов и зайдите в базу сами. Если ошибка ушла — разрешайте работу.

Чистка серверного кэша 1С на Linux

Принцип тот же, отличаются команды. Имя службы зависит от версии платформы: в старых установках это srv1cv83, в новых — systemd-юнит вида srv1cv8-8.3.xx.yyyy@default, где вместо xx.yyyy номер вашей версии.

# найти точное имя службы
systemctl list-units --type=service | grep -i 1cv8

# остановить (пример для юнита новой версии)
sudo systemctl stop srv1cv8-8.3.24.1548@default

# убедиться, что процессы остановлены
ps aux | grep -E "ragent|rmngr|rphost" | grep -v grep

# копия и очистка кэша
sudo cp -a /home/usr1cv8/.1cv8/1C/1cv8 /root/srvinfo_backup_$(date +%F)
sudo rm -rf /home/usr1cv8/.1cv8/1C/1cv8/reg_1541/snccntx*

# запуск
sudo systemctl start srv1cv8-8.3.24.1548@default

Номер версии в примере условный — возьмите свой из вывода первой команды.

Консоль администрирования: освободить память без остановки сервера

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

Что посмотреть перед вмешательством

В консоли откройте кластер и раздел «Рабочие процессы». Там видно:

• 📊 сколько памяти занимает каждый процесс;
• 👥 сколько на нём соединений и сеансов;
• ⏱ среднее время обработки вызовов.

Если один процесс занимает в разы больше памяти, чем остальные, и не уменьшается часами — это кандидат на перезапуск.

Та же информация доступна из командной строки через сервер администрирования ras и утилиту rac:

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

Остальные подкоманды смотрите в справке rac help — она перечисляет всё, что поддерживает ваша версия.

Настройки кластера, которые делают это автоматически

В свойствах кластера (правый щелчок по кластеру → «Свойства») есть параметры, которые заставляют сервер сам периодически обновлять рабочие процессы:

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

Очистка кэша на стороне базы данных и клиентов

Слово «кэш» в разговорах про сервер 1С часто означает разные вещи. Разведём их.

Кэш СУБД — чистить не нужно

SQL Server и PostgreSQL держат в памяти страницы данных и планы запросов. Это их нормальная работа. Команды вроде DBCC DROPCLEANBUFFERS или DBCC FREEPROCCACHE на рабочем сервере только замедлят всех: СУБД придётся заново читать данные с диска.

Если база тормозит, полезнее другое:

• обновить статистику (sp_updatestats в MS SQL, ANALYZE в PostgreSQL);
• перестроить фрагментированные индексы;

Конфигурация базы данных

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

Кэш пользователей на терминальном сервере

Если 1С запускается на терминальном сервере, у каждого пользователя есть свой клиентский кэш. Он лежит в профиле:

• %APPDATA%\1C\1cv8\
• %LOCALAPPDATA%\1C\1cv8\

Внутри — папки с длинными именами-GUID, по одной на каждую базу. Их можно удалить, когда у пользователя закрыта 1С. Файлы ibases.v8i и 1CEStart.cfg в %APPDATA%\1C\1CEStart\ не трогайте: в них список баз.

Более мягкий вариант — запустить 1С с параметром /ClearCache. В свойствах ярлыка допишите в конец строки запуска:

"C:\Program Files\1cv8\common\1cestart.exe" /ClearCache

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

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

Регулярно удалять snccntx* без причины не нужно. Но если сервер после каждого обновления «залипает», удобно иметь готовый скрипт, который вы запустите одной командой или повесите на ночь после регламентного обновления.

Пример для PowerShell. Он сам находит службу, останавливает её, ждёт завершения процессов, делает копию и чистит только кэш сеансов:

$srvinfo = "C:\Program Files\1cv8\srvinfo"
$backup  = "D:\backup\srvinfo_" + (Get-Date -Format "yyyy-MM-dd_HHmm")

$svc = Get-Service | Where-Object { $_.Name -like "1C:Enterprise 8.3 Server Agent*" } | Select-Object -First 1
if (-not $svc) { Write-Error "Служба агента 1С не найдена"; exit 1 }

Stop-Service -Name $svc.Name -Force
$deadline = (Get-Date).AddMinutes(3)
while ((Get-Process rphost, rmngr, ragent -ErrorAction SilentlyContinue) -and (Get-Date) -lt $deadline) {
    Start-Sleep -Seconds 5
}

Copy-Item -Path $srvinfo -Destination $backup -Recurse
Get-ChildItem -Path $srvinfo -Directory -Filter "reg_*" |
    ForEach-Object { Get-ChildItem -Path $_.FullName -Directory -Filter "snccntx*" } |
    Remove-Item -Recurse -Force

Start-Service -Name $svc.Name

Как поставить на расписание:

1. Сохраните скрипт, например, в C:\Scripts\clear_1c_cache.ps1.
2. Откройте «Планировщик заданий» Windows и создайте задачу.
3. Запуск — от имени администратора, с флажком «Выполнять с наивысшими правами».
4. Действие: программа powershell.exe, аргументы -ExecutionPolicy Bypass -File C:\Scripts\clear_1c_cache.ps1.
5. Время — ночью, когда нет пользователей и не идут регламентные задания 1С и резервное копирование СУБД.

Старые копии srvinfo в папке резервных копий не забывайте удалять: каждая весит от десятков мегабайт до нескольких гигабайт из-за журналов регистрации.

Как реже сталкиваться с проблемами кэша на сервере

Большая часть «кэшевых» сбоев имеет понятную причину. Если её убрать, чистить вообще не придётся.

Что из этого чаще всего недооценивают:

• 🛡 Антивирус. Сканирование файлов в srvinfo на лету блокирует их в момент записи. Отсюда повреждённые файлы контекстов и странные ошибки при входе.
• 💾 Диск. Журнал регистрации и индекс полнотекстового поиска растут годами. Когда место кончается, кластер пишет неполные файлы, и после этого кэш приходится чистить.
• 🔢 Версии. Клиент и сервер должны быть одной сборки, номер в номер. Иначе подключение отклоняется ещё до обращения к кэшу, но симптомы похожи.
• ⚡ SSD. Каталог srvinfo на быстром диске заметно ускоряет первый вход в базу после перезапуска.

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