Кэш сервера 1С: где находится и как его очистить

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

Главная сложность в том, что под «кэшем сервера 1С» понимают сразу несколько разных хранилищ: каталог srvinfo с настройками кластера, папки сеансовых данных внутри него, а также локальный кэш метаданных на клиентских компьютерах. Путать их нельзя: очистка клиентского кэша и очистка серверного решают разные задачи и выполняются по-разному.

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

Где находится каталог srvinfo на Windows и Linux

Основное хранилище служебных данных кластера — каталог srvinfo. Его расположение зависит от операционной системы и от того, как была установлена платформа.

На Windows при установке «по умолчанию» каталог находится по пути C:\Program Files\1cv8\srvinfo. Если служба агента сервера запущена под отдельным пользователем USR1CV8, данные также могут лежать в профиле этой учётной записи. На Linux типовой путь — /opt/1cv8/x86_64/<номер версии>/srvinfo либо домашний каталог пользователя, под которым работает агент: /home/usr1cv8/.1cv8/1C/1cv8.

Точный путь всегда можно посмотреть в параметрах запуска службы агента сервера: он задаётся ключом -d. В Windows это видно в свойствах службы «Агент сервера 1С:Предприятия» (строка «Исполняемый файл»), в Linux — в unit-файле systemd или скрипте запуска. Полагаться на память не стоит: при переносе кластера или нестандартной установке каталог мог быть переопределён.

sc qc "1C:Enterprise 8.3 Server Agent"

Вывод команды покажет строку запуска, где после ключа -d указан реальный путь к каталогу кластера. На Linux аналогичную информацию даёт команда просмотра параметров процесса:

ps aux | grep ragent

Что хранится внутри srvinfo: структура папок

Внутри srvinfo находится один или несколько подкаталогов вида reg_1541, где число — порт главного менеджера кластера. Для стандартной установки это reg_1541. Если на одном сервере работает несколько кластеров с разными портами, папок будет несколько, и важно не перепутать, какая из них относится к нужному кластеру.

Внутри каталога регистрации кластера лежат файлы и подпапки с разным назначением. Файл 1CV8Clst.lst содержит список зарегистрированных информационных баз кластера — его удаление «отвяжет» базы от кластера, и их придётся регистрировать заново. Подкаталоги snccntx (или файлы сеансовых данных) хранят контексты сеансов, временные блокировки и служебную информацию о соединениях — именно эти данные чаще всего называют «кэшем», который нужно чистить.

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

Частая ошибка — смешивать кэш сервера 1С и кэш на компьютере пользователя. Клиентский кэш метаданных хранится в профиле пользователя: на Windows это папки %APPDATA%\1C\1cv8 и %LOCALAPPDATA%\1C\1cv8, где лежат каталоги с длинными именами-идентификаторами баз. Он содержит локально скомпилированные модули и настройки интерфейса конкретного пользователя.

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

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

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

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

Пошаговая процедура безопасной очистки

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

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

1. 1
   Предупредите пользователей и завершите активные сеансы через консоль кластера
2. 2
   Остановите службу агента сервера 1С (services.msc или systemctl stop srv1cv8)
3. 3
   Сделайте полную копию каталога srvinfo в архив или отдельную папку
4. 4
   Удалите файлы блокировок (*.lck) и содержимое подкаталогов сеансовых данных, не трогая 1CV8Clst.lst
5. 5
   Запустите службу агента сервера
6. 6
   Проверьте в консоли кластера, что базы зарегистрированы и доступны
7. 7
   Выполните тестовый вход в каждую рабочую базу и запустите типовую операцию

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

Проверка результата и типичные ошибки

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

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

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