Каталоги snccntx на сервере 1С: зачем они нужны и когда их удалять

Файл snccntx.dat в 1С — это часть служебного кэша сервера 1С:Предприятия. Он лежит в каталоге snccntx… внутри данных кластера (srvinfo\reg_1541) и хранит рабочий контекст информационной базы, который сервер собирает при обращении к ней. Данных учёта в нём нет: удалённый каталог сервер создаст заново при следующем подключении к базе.

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

Что хранит snccntx.dat и зачем он нужен серверу 1С

Сервер 1С держит для каждой информационной базы свой набор служебных файлов. Часть из них важна и уникальна (реестр кластера), часть — производная, которую можно пересобрать. Каталоги snccntx и файл snccntx.dat относятся ко второй группе.

Что важно знать о них на практике:

• 🗂 Это кэш, а не данные. Документы, справочники и регистры хранятся в СУБД (MS SQL, PostgreSQL) или в файле 1Cv8.1CD. В snccntx их нет.
• 🔁 Пересоздаётся автоматически. После удаления каталога первый вход в базу пройдёт чуть дольше, дальше всё работает как раньше.
• 🧩 Привязан к базе. У каждой базы на сервере свой каталог со своим идентификатором в имени (snccntx + GUID).
• ⚡ Ускоряет работу. Серверу не нужно при каждом подключении заново собирать служебные структуры базы.

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

Чем кэш сервера отличается от кэша клиента

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

Где лежит файл snccntx.dat на Windows и Linux

Каталоги snccntx находятся в рабочем каталоге кластера. Его имя строится по номеру порта менеджера кластера: reg_1541 для стандартного порта 1541, reg_2541 — для кластера на порту 2541 и так далее.

Типичные пути:

Внутри reg_1541 лежат файлы реестра кластера и каталоги баз, названные по их идентификаторам. Искать нужно каталоги, имя которых начинается с snccntx. В зависимости от версии платформы они лежат прямо в reg_1541 или во вложенных каталогах баз, поэтому проще найти их поиском по маске.

Как найти точный путь на своём сервере

Установщик позволяет задать другой каталог данных, поэтому путь «по умолчанию» есть не везде. Точное место видно в параметрах службы агента:

1. Откройте services.msc.
2. Найдите службу «Агент сервера 1С:Предприятия 8.3».
3. Откройте её свойства и посмотрите строку «Исполняемый файл».
4. Каталог указан после ключа -d. Например: -d "D:\1C\srvinfo".

Поиск каталогов по маске в PowerShell:

Get-ChildItem -Path "C:\Program Files\1cv8\srvinfo" -Recurse -Directory -Filter "snccntx*" |
  Select-Object FullName, LastWriteTime

На Linux:

sudo find /home/usr1cv8/.1cv8/1C/1cv8 -maxdepth 3 -type d -name 'snccntx*'

Когда виноват кэш: признаки повреждённого контекста базы

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

Признаки, при которых стоит проверить snccntx:

• 🔄 После обновления конфигурации часть пользователей видит старые формы или старый состав объектов, хотя «Обновление конфигурации базы данных» прошло без ошибок.
• 🐢 Вход в одну конкретную базу на сервере стал заметно дольше, а другие базы на том же сервере работают нормально.
• ❌ При входе или открытии объектов появляются ошибки обращения к метаданным, которые не воспроизводятся в копии базы на другом сервере.
• 💥 Проблемы начались после аварийного выключения сервера, переполнения диска или принудительного завершения процессов rphost.
• 🧱 Обновление через Конфигуратор прошло, а изменения в режиме «Предприятие» не видны даже после перезапуска клиента.

Прежде чем трогать сервер, исключите клиентскую сторону. Запустите 1С у одного пользователя с ключом /ClearCache:

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

Если после этого у него всё в порядке — дело было в кэше клиента, сервер трогать не нужно.

Как безопасно очистить snccntx: пошагово

Очистка занимает 5-10 минут, но требует остановки службы. Делайте это вне рабочего времени.

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

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

1. Сообщите пользователям время работ.
2. В консоли администрирования серверов 1С откройте кластер, раздел сеансов, и проверьте, кто ещё работает.
3. Дождитесь завершения длительных операций: закрытия месяца, обменов, загрузок.

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

На Windows — через services.msc или PowerShell от имени администратора:

Get-Service | Where-Object { $_.Name -like "1C:Enterprise 8.3 Server Agent*" } | Stop-Service

На Linux имя службы зависит от версии платформы. Посмотрите его командой:

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

И остановите найденную службу через sudo systemctl stop <имя>.

Проверьте, что процессы ragent, rmngr и rphost действительно завершились. В диспетчере задач Windows или командой ps aux | grep -E 'ragent|rmngr|rphost' на Linux.

Шаг 3. Сделайте копию каталога кластера

Скопируйте весь каталог srvinfo (или reg_1541) в другое место. Он небольшой, копирование занимает секунды. Если что-то пойдёт не так, вы вернёте всё как было.

Шаг 4. Удалите каталоги snccntx

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

Если проблема только в одной базе, можно удалить только её каталог. Если не знаете, какой каталог чей, удалите все snccntx* — сервер пересоздаст каждый при первом входе в соответствующую базу.

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

1. Запустите агент сервера (Start-Service или systemctl start).
2. Зайдите в проблемную базу. Первый вход будет дольше обычного — сервер собирает контекст заново.
3. Проверьте, появился ли новый каталог snccntx с текущей датой изменения.
4. Убедитесь, что симптом пропал: формы актуальны, ошибка не повторяется.

Что внутри snccntx.dat и можно ли его прочитать

Формат файла не опубликован. Открывать snccntx.dat текстовым редактором бесполезно: внутри двоичные данные, читаемых строк там почти нет.

Что можно узнать без «вскрытия» файла:

• 📅 Дата изменения. Если каталог базы не обновлялся с момента обновления конфигурации, а проблемы начались сразу после него, это аргумент за очистку.
• 📏 Размер. Он зависит от размера конфигурации. Для крупных конфигураций вроде ERP кэш заметно больше, чем для Бухгалтерии. Резкий рост размера сам по себе не ошибка.
• 🆔 Идентификатор в имени. По нему можно понять, к какой базе относится каталог: он совпадает с идентификатором базы в реестре кластера и в имени соседнего каталога базы.

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

1. Посмотрите идентификаторы баз через утилиту rac (команда rac infobase summary list --cluster=<id кластера>; идентификатор кластера даёт rac cluster list).
2. Найдите идентификатор нужной базы в имени каталога snccntx… или в имени соседнего каталога базы.
3. Если формат вывода у вас отличается, смотрите справку rac help infobase.

Профилактика и автоматизация очистки кэша сервера

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

Что реально снижает число проблем с кэшем:

• 💾 Свободное место на диске с srvinfo. Переполненный диск — частая причина повреждения служебных файлов. Держите запас и следите за ростом журналов регистрации, они лежат там же.
• 🔌 Корректное завершение службы. Перед перезагрузкой сервера останавливайте агент 1С, а не полагайтесь на то, что Windows завершит его сама.
• 🛡 Исключения в антивирусе. Добавьте каталог srvinfo в исключения проверки в реальном времени. Антивирус, который блокирует файлы кэша во время записи, — классический источник странных сбоев.
• 🔄 Перезапуск после обновления платформы. После установки новой версии платформы на сервер перезапустите службу целиком.

Скрипт для планового обслуживания

Если очистка нужна в рамках регламента — например, раз в квартал или после каждого крупного обновления конфигурации, — её можно поставить в планировщик заданий Windows на ночное время:

# Очистка серверного кэша 1С. Запускать от имени администратора в нерабочее время.
$srvinfo = "C:\Program Files\1cv8\srvinfo"
$backup  = "D:\Backup\srvinfo_" + (Get-Date -Format "yyyyMMdd_HHmm")

$svc = Get-Service | Where-Object { $_.Name -like "1C:Enterprise 8.3 Server Agent*" }
$svc | Stop-Service -Force
Start-Sleep -Seconds 30

Copy-Item -Path $srvinfo -Destination $backup -Recurse

Get-ChildItem -Path $srvinfo -Recurse -Directory -Filter "snccntx*" |
  Remove-Item -Recurse -Force

$svc | Start-Service

Перед первым запуском проверьте путь к srvinfo по ключу -d в свойствах службы и пропишите свой. Пауза в 30 секунд нужна, чтобы процессы rphost успели завершиться.

Для Linux то же самое делается коротким bash-скриптом с systemctl stop, cp -a и find … -name 'snccntx*' -exec rm -rf {} +, запуском через cron.

Частые ошибки при очистке кэша

• ❌ Удалили весь каталог reg_1541. Вместе с кэшем пропал реестр кластера. Базы придётся регистрировать заново, а заодно восстанавливать настройки рабочих серверов и администраторов. Лечится только копией каталога.
• ❌ Чистили при работающей службе. Часть файлов занята процессами и не удалится, а оставшиеся могут оказаться в несогласованном состоянии.
• ❌ Чистили не тот сервер. В кластере из нескольких рабочих серверов служебные каталоги есть на каждом. Если базы обслуживаются на нескольких машинах, проверьте каждую.
• ❌ Искали проблему на сервере, а она у клиента. Если сбой у одного пользователя, очистка сервера ничего не даст, а остальным сотрудникам вы сорвёте работу.
• ❌ Очистка как «лекарство от всего». Если после удаления кэша ошибка вернулась через день, причина в другом: в самой базе, в железе или в конфигурации.

Частые вопросы про snccntx.dat