Как почистить кэш сервера 1С: полная инструкция для администратора

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

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

Ниже разобрано, где физически лежит кэш на Windows и Linux, какие каталоги можно удалять, а какие трогать нельзя, как выполнить очистку по шагам и как убедиться, что после перезапуска всё работает корректно.

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

Кластер серверов 1С кэширует данные на уровне рабочих процессов и на уровне файловой системы. В оперативной памяти держатся скомпилированные модули и метаданные, а на диске — служебные каталоги внутри папки srvinfo: журнал регистрации кластера, список информационных баз, снимки сеансовых данных и кэш контекстов (snccntx). Именно файловый кэш чаще всего становится источником проблем после аварийного завершения работы сервера, перебоев с питанием или нештатного обновления платформы.

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

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

На Windows кэш агента сервера по умолчанию располагается в профиле служебного пользователя, под которым работает служба «Агент сервера 1С:Предприятия». Типовые пути: C:\Program Files\1cv8\<версия>\bin — это каталог программы, а данные кластера лежат отдельно: C:\Program Files\1cv8\srvinfo либо C:\Users\USR1CV8\AppData\Local\1C\1cv8 — в зависимости от того, как был установлен и настроен сервер. Точный путь можно посмотреть в свойствах службы агента: параметр запуска -d указывает на каталог кластера.

На Linux кэш обычно находится в домашнем каталоге пользователя, под которым запущен агент: /home/usr1cv8/.1cv8/1C/1cv8/, либо в каталоге, заданном параметром -d при запуске демона. Внутри находится папка srvinfo, а в ней — подкаталоги вида reg_1541 (номер зависит от порта кластера), snccntx, файлы 1CV8Clst.lst, 1CV8Clsto.lst и журналы.

Что можно удалять, а что трогать нельзя

Внутри srvinfo содержимое делится на три группы. Первая — данные, которые удалять нельзя: файл списка баз 1CV8Clst.lst и, если он нужен для анализа, журнал регистрации кластера (папка с файлами 1Cv8Log). Вторая группа — кэш, который безопасно удаляется: каталог snccntx (кэш сеансовых данных и контекстов), содержимое подпапок reg_1541 с временными файлами сеансов, файлы блокировок *.lck, оставшиеся после аварийной остановки. Третья группа — журналы и дампы: их можно архивировать и удалять для освобождения места, но это не влияет на работоспособность кэша.

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

Пошаговая очистка кэша на Windows

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

1. 1
   Откройте services.msc и остановите службу «Агент сервера 1С:Предприятия» нужной версии платформы
2. 2
   Дождитесь полной остановки: в диспетчере задач не должно остаться процессов ragent, rmngr и rphost
3. 3
   Перейдите в каталог srvinfo (точный путь смотрите в параметре -d в свойствах службы)
4. 4
   Удалите папку snccntx и временные файлы внутри reg_1541, не трогая 1CV8Clst.lst
5. 5
   Запустите службу агента сервера и проверьте, что базы видны в консоли кластера
6. 6
   Войдите в одну из баз тестовым сеансом и убедитесь, что ошибки исчезли

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

Пошаговая очистка кэша на Linux

На Linux логика та же: сначала остановка демона, затем удаление кэша, затем запуск. Команды выполняются от root или через sudo. Имя службы зависит от версии платформы и способа установки, типовой вариант — srv1cv83.

systemctl stop srv1cv83
ps aux | grep -E 'ragent|rmngr|rphost'
rm -rf /home/usr1cv8/.1cv8/1C/1cv8/srvinfo/snccntx
systemctl start srv1cv83
tail -f /home/usr1cv8/.1cv8/1C/1cv8/srvinfo/reg_1541/*.log

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

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

Проверка состоит из трёх шагов. Первый — служба агента запущена и не падает: на Windows статус «Выполняется» в services.msc, на Linux systemctl status srv1cv83 показывает active (running). Второй — в консоли администрирования кластера видны все информационные базы и рабочие процессы. Третий — реальный вход в базу под тестовой учётной записью и выполнение операции, которая раньше вызывала ошибку.

Частые ошибки и профилактика

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

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