Папка srvinfo и её содержимое: что из кэша сервера 1С можно удалять, а что нельзя

Серверный кэш 1С 8.3 лежит в каталоге кластера srvinfo. В Windows по умолчанию это C:\Program Files\1cv8\srvinfo\reg_1541\, в Linux — /home/usr1cv8/.1cv8/1C/1cv8/reg_1541/. Временные данные сеансов там хранятся в папках snccntx* — именно их и удаляют при «очистке кэша сервера», предварительно остановив службу агента.

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

Где сервер 1С 8.3 хранит кэш по умолчанию

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

Внутри лежит подкаталог reg_<порт>. Число в имени — порт менеджера кластера. При стандартной установке это 1541, отсюда reg_1541. Если кластер запущен на другом порту, папка будет называться иначе, например reg_2541.

Как узнать реальный путь, если его меняли

Администраторы часто переносят srvinfo на отдельный диск. Путь задаёт ключ -d в командной строке службы агента.

• 🪟 Windows: откройте services.msc, найдите службу «Агент сервера 1С:Предприятия 8.3», в свойствах посмотрите поле «Исполняемый файл». Там будет строка вида ragent.exe -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "D:\1C\srvinfo".
• 🐧 Linux: выполните ps aux | grep ragent и найдите в выводе тот же ключ -d.

Если ключа -d нет, работает путь по умолчанию из таблицы выше.

Что лежит в reg_1541: разбор папок и файлов

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

Папки snccntx при работе кластера постоянно растут. На загруженном сервере их бывает несколько десятков, а суммарный объём доходит до гигабайтов. Это нормальное поведение, но после аварийных остановок там остаётся «мусор», который мешает сеансам.

Файл 1CV8Clst.lst перед любыми работами скопируйте в отдельное место. Это пять секунд, а восстановление списка баз вручную — полдня.

Файловая база и клиент-серверная: где кэш в каждом случае

У файловой базы сервера 1С нет, а значит, нет и srvinfo. Вся «серверная» часть работает внутри клиентского процесса на компьютере пользователя.

Клиентский кэш одинаков для обоих режимов:

• 🪟 Windows: %APPDATA%\1C\1cv8\ и %LOCALAPPDATA%\1C\1cv8\. Внутри — папки с длинными именами-GUID, по одной на каждую базу из списка.
• 🐧 Linux: ~/.1cv8/1C/1cv8/.

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

Пошаговая очистка кэша на сервере 1С

Процедура одна для Windows и Linux, различаются только команды. Делайте её вне рабочего времени.

Шаг 1. Завершите сеансы и остановите службу

1. Откройте консоль администрирования серверов 1С и убедитесь, что в базах нет активных сеансов. Если есть — попросите пользователей выйти.
2. Остановите службу агента.

Windows (PowerShell от имени администратора):

# узнать точное имя службы
Get-Service | Where-Object { $_.DisplayName -like "*1C*" }

# остановить (подставьте имя из вывода выше)
Stop-Service -Name "1C:Enterprise 8.3 Server Agent (x86-64)"

Linux. Начиная с платформы 8.3.21 сервер ставится как systemd-сервис с номером версии в имени. На более ранних версиях использовался сценарий srv1cv83.

# найти службу
systemctl list-units --type=service | grep -i 1c

# остановить (имя возьмите из вывода)
sudo systemctl stop srv1cv8-8.3.24.1548@default

3. Проверьте, что процессы ragent, rmngr и rphost действительно завершились. В Windows — в «Диспетчере задач» на вкладке «Подробности», в Linux — ps aux | grep -E "ragent|rmngr|rphost".

Шаг 2. Сохраните реестр кластера

Скопируйте srvinfo\1cv8wsrv.lst и srvinfo\reg_1541\1CV8Clst.lst в отдельную папку. Если что-то пойдёт не так, достаточно будет вернуть эти два файла на место.

Шаг 3. Удалите папки кэша сеансов

Удаляйте только каталоги, имя которых начинается с snccntx.

Remove-Item "C:\Program Files\1cv8\srvinfo\reg_1541\snccntx*" -Recurse -Force

sudo rm -rf /home/usr1cv8/.1cv8/1C/1cv8/reg_1541/snccntx*

Если путь у вас нестандартный, подставьте значение ключа -d, найденное раньше.

Шаг 4. Верните службу в работу

Start-Service -Name "1C:Enterprise 8.3 Server Agent (x86-64)"

sudo systemctl start srv1cv8-8.3.24.1548@default

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

Кэш расширений и внешних компонент

Расширения конфигурации хранятся в самой информационной базе. Отдельного «каталога расширений» на сервере нет. При запуске клиент получает их вместе с остальными метаданными и складывает в свой кэш — в те же GUID-папки в %APPDATA%\1C\1cv8\.

Отсюда частый случай: расширение обновили, а у пользователя работает старая версия. Обычно хватает перезапуска клиента, иногда — запуска с /ClearCache.

С внешними компонентами сложнее, у них две стороны:

• 💻 На клиенте. Установленные компоненты платформа хранит в профиле пользователя, в каталоге %APPDATA%\1C\1cv8\ExtCompT\. Если компонента (например, для торгового оборудования) ведёт себя странно после обновления, удалите её из этой папки при закрытой 1С — при следующем вызове она установится заново.
• 🖥 На сервере. Компоненты, которые выполняются в рабочем процессе, распаковываются во временный каталог пользователя, от имени которого работает служба. Если компонента «залипла» на старой версии, помогает перезапуск службы агента — с тем же предупреждением о сеансах.

Облако: 1С:Фреш и 1С:Линк

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

1С:Фреш. Кластер обслуживает провайдер. Что можно сделать самостоятельно:

1. Очистить кэш на своей стороне. Для тонкого клиента — /ClearCache или удаление GUID-папки базы в %APPDATA%\1C\1cv8\.
2. Для работы через браузер — очистить кэш и файлы cookie браузера для адреса сервиса или открыть базу в режиме инкогнито для проверки.
3. Если проблема сохраняется у всех пользователей приложения — писать в поддержку сервиса. Это уже серверная сторона.

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

• база файловая — клиентские папки на компьютерах пользователей;
• база на вашем сервере 1С — srvinfo этого сервера, и очищается он по шагам выше.

Как автоматизировать очистку кэша

Ручная чистка раз в квартал — нормально. Если snccntx разрастается каждую неделю, процедуру стоит поставить в расписание. Но автоматизировать её без проверок опасно: скрипт, удаливший не ту папку, сломает кластер ночью, когда никого нет.

Пример для Windows. Сценарий сохраняет реестр, останавливает службу, удаляет только snccntx* и пишет журнал.

$Service = "1C:Enterprise 8.3 Server Agent (x86-64)"
$Reg     = "C:\Program Files\1cv8\srvinfo\reg_1541"
$Backup  = "D:\1C_backup\srvinfo_" + (Get-Date -Format "yyyyMMdd_HHmm")
$Log     = "D:\1C_backup\clear_cache.log"

New-Item -ItemType Directory -Path $Backup -Force | Out-Null
Copy-Item "$Reg\1CV8Clst.lst" $Backup
Copy-Item "$Reg\..\1cv8wsrv.lst" $Backup

Stop-Service -Name $Service -Force
Start-Sleep -Seconds 20

# проверяем, что рабочие процессы завершились
if (Get-Process rphost -ErrorAction SilentlyContinue) {
    Add-Content $Log "$(Get-Date) rphost ещё работает, очистка отменена"
    Start-Service -Name $Service
    exit 1
}

Remove-Item "$Reg\snccntx*" -Recurse -Force
Start-Service -Name $Service
Add-Content $Log "$(Get-Date) кэш очищен, служба запущена"

Запускайте его через «Планировщик заданий» от имени администратора, например в воскресенье в 03:00. Время выбирайте так, чтобы оно не пересекалось с регламентными заданиями баз и резервным копированием SQL.

Для Linux логика та же: cp двух файлов, systemctl stop, проверка pgrep rphost, rm -rf .../snccntx*, systemctl start. Сценарий ставится в cron пользователя root.

Альтернатива полной остановке — штатный перезапуск рабочих процессов. В свойствах рабочего сервера в консоли администрирования можно задать ограничения по памяти для процессов. Тогда «распухший» rphost будет перезапускаться сам, без остановки всего кластера. Это не очищает snccntx, но часто снимает ту же проблему с памятью.

Ошибки, которые лечатся очисткой серверного кэша, и те, что не лечатся

Не всякий сбой — от кэша. Перед остановкой службы сверьтесь с таблицей ниже.

Ещё одна ловушка — права доступа. Если вы удаляли папки от имени своего администратора, а не от пользователя службы, новые snccntx создаются нормально. Но если вы копировали файлы реестра обратно, проверьте, что у USR1CV8 (или usr1cv8 в Linux) осталось право на запись в reg_1541. Без него агент стартует и сразу останавливается.

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