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

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

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

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

Где именно лежит серверный кэш: каталог srvinfo

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

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

На Linux каталог кластера задаётся аналогичным ключом -d в юните systemd или скрипте запуска агента. Типичные варианты: /opt/1cv8/x86_64/<версия>/srvinfo или /home/usr1cv8/.1cv8/1cv8, если сервер запущен от пользователя usr1cv8 без явного указания каталога. Проверить фактический путь проще всего командой просмотра параметров процесса:

ps aux | grep ragent | grep -v grep

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

Что находится внутри: структура папок кластера

Внутри srvinfo расположен подкаталог вида reg_1541 — номер соответствует порту главного менеджера кластера (по умолчанию 1541). Если на сервере несколько кластеров, будет несколько таких папок с разными номерами портов. Именно в reg_1541 сосредоточены основные служебные данные.

Типовое содержимое reg_1541:

• 1CV8Clst.lst — реестр кластера: список информационных баз, рабочих процессов, настройки. Не кэш, удалять нельзя.
• 1CV8Clstr.lst и файлы блокировок — служебные данные агента.
• Папки с GUID-именами — каталоги информационных баз, зарегистрированных в кластере. Внутри каждой — сеансовые данные, кэш метаданных, файлы фоновых заданий.
• snccntx.dat и подобные — данные сеансов и контекстов.
• Журналы кластера и технологический журнал, если он включён.

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

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

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

Клиентский кэш лежит в профиле пользователя: %APPDATA%\1C\1cv8 и %LOCALAPPDATA%\1C\1cv8 на Windows, ~/.1cv8 на Linux-клиенте. Там хранятся кэш метаданных тонкого и толстого клиента в папках вида snccntx и GUID-каталогах баз. Признак клиентской проблемы: ошибка возникает только у одного пользователя или на одном компьютере, у остальных та же база работает нормально.

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

Безопасная очистка кэша сервера 1С

Главное правило: не удалять файлы кэша при работающем агенте сервера. Файлы сеансов открыты процессами rphost и ragent, попытка удаления «на живую» либо заблокируется, либо приведёт к рассинхронизации состояния кластера и падению сеансов пользователей.

Рекомендуемый порядок действий:

1. 1
   Предупредите пользователей и завершите активные сеансы через консоль кластера или дождитесь нерабочего времени
2. 2
   Остановите службу агента сервера 1С (на Windows — services.msc, на Linux — systemctl stop srv1cv8 или аналогичный юнит)
3. 3
   Убедитесь, что процессы ragent, rphost, rmngr завершены
4. 4
   Перейдите в srvinfo\reg_1541 и удалите содержимое GUID-папок баз и файлы сеансовых данных, не трогая 1CV8Clst.lst
5. 5
   При необходимости очистите клиентский кэш на проблемных машинах
6. 6
   Запустите службу агента и проверьте вход в базу, выполнение типовых операций и фоновых заданий

Более мягкая альтернатива полной остановке — перезапуск рабочих процессов через консоль администрирования кластера. Во многих случаях перезапуск rphost заставляет платформу перечитать и пересоздать кэш без ручного удаления файлов. Этот способ предпочтителен, если нельзя останавливать весь кластер.

На Linux не забудьте про права доступа: после любых ручных операций внутри srvinfo владельцем файлов должен остаться пользователь, от которого работает агент (обычно usr1cv8). Если файлы создавались или изменялись от root, агент может не стартовать — проверьте владельца командой ls -la и при необходимости выполните chown -R usr1cv8:grp1cv8 на каталог.

Когда очистка кэша действительно помогает

Очистка кэша — не универсальное лекарство, а инструмент для конкретного набора симптомов. Оправдана она в следующих случаях:

• После обновления конфигурации база выдаёт ошибки вида «Ошибка формата потока», «неверный формат хранилища данных» или не находит процедуры, которые явно существуют в конфигурации.
• Рабочие процессы rphost аварийно завершаются сразу после старта сеанса, при этом сама база через другой сервер или файловый вариант открывается нормально.
• Каталог srvinfo занимает неоправданно много места, и в GUID-папках накопились файлы многомесячной давности.
• После восстановления базы из копии или переноса на другой сервер наблюдаются «фантомные» ошибки сеансов.

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

Контроль размера и профилактика

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

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

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