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

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

На Windows по умолчанию это каталог C:\Program Files\1cv8\srvinfo\, на Linux — /opt/1cv8/x86_64/<версия>/srvinfo или /var/lib/1cv8 в зависимости от способа установки. Внутри находятся подкаталоги вида reg_1541, где 1541 — порт агента кластера, а в них — папки с GUID информационных баз и файлы кэша.

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

Где физически находится серверный кэш 1С

Местоположение кэша задаётся параметром -d при запуске агента сервера 1С. Если при установке значение не меняли, используется путь по умолчанию, который зависит от операционной системы и версии платформы.

• Windows, установка по умолчанию: C:\Program Files\1cv8\srvinfo\ (для 32-битной версии на 64-битной ОС — C:\Program Files (x86)\1cv8\srvinfo\).
• Linux (пакеты 1С): /opt/1cv8/x86_64/<номер версии>/srvinfo; часто встречается и /var/lib/1cv8/.1cv8/1C/1cv8/, если агент запущен от пользователя srv1cv8 с домашним каталогом.
• Нестандартный путь: смотрите параметр -d в строке запуска службы «Агент сервера 1С:Предприятия» (в реестре Windows — HKLM\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3 Server Agent, значение ImagePath).

Обратите внимание: если на сервере установлено несколько версий платформы и работают несколько агентов, у каждого может быть свой каталог srvinfo. Найдите активный именно через параметр запуска службы, а не по привычному пути.

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3 Server Agent*' | Select-Object ImagePath

Структура каталога srvinfo: что лежит внутри

Внутри srvinfo находится один или несколько каталогов вида reg_1541, reg_2541 и т.д. Число в имени — порт агента кластера. Каждый такой каталог — это данные отдельного кластера серверов.

В каталоге кластера находятся:

• 1CV8Clst.lst — список зарегистрированных информационных баз кластера;
• папки с GUID в имени (например, a1b2c3d4-…) — рабочие каталоги каждой базы, именно здесь лежит кэш метаданных и скомпилированных модулей;
• файлы журналов, блокировок и служебные данные сеансов.

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

Как найти, какая папка соответствует нужной базе

Имена GUID не говорят напрямую, какой папке какая база соответствует. Есть два рабочих способа сопоставления.

Первый — через консоль администрирования серверов 1С. Откройте свойства информационной базы в ветке кластера: там указан её GUID, который совпадает с именем папки в reg_1541. Второй способ — открыть файл 1CV8Clst.lst текстовым редактором: в нём перечислены имена баз и их идентификаторы.

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

1. 1
   Откройте консоль администрирования серверов 1С и найдите нужную базу
2. 2
   Скопируйте GUID базы из её свойств
3. 3
   Откройте srvinfo\reg_1541 и найдите папку с этим GUID
4. 4
   Проверьте по дате изменения, что папка активно используется

Когда и как безопасно очищать серверный кэш

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

Порядок безопасной очистки:

1. Завершите сеансы пользователей в консоли кластера или дождитесь нерабочего времени.
2. Остановите службу «Агент сервера 1С:Предприятия» (net stop "1C:Enterprise 8.3 Server Agent" или systemctl stop srv1cv83 на Linux).
3. Удалите содержимое папок с GUID нужных баз внутри reg_1541, не трогая 1CV8Clst.lst и сам каталог кластера.
4. Запустите службу и проверьте вход в базу.

Более мягкая альтернатива полной остановке — команда rac cluster … --kill-process не применяется, но можно перезапустить только рабочие процессы или использовать параметр кластера, сбрасывающий кэш при рестарте. На практике чаще всего достаточно остановки службы на несколько минут.

Отличие серверного кэша от клиентского

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

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

Типичные ошибки при работе с srvinfo

Первая и самая опасная — удаление всего каталога srvinfo или файла 1CV8Clst.lst. После этого кластер «забывает» все зарегистрированные базы, и их приходится добавлять заново вручную, указывая параметры подключения к СУБД.

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

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

Контроль объёма и профилактика

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

Полезные меры: размещать srvinfo не на системном диске (путь задаётся параметром -d службы агента), удалять регистрацию неиспользуемых баз из кластера вместе с их GUID-папками и планировать очистку кэша только после крупных обновлений, а не по расписанию.

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