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

Кэш сервера 1С:Предприятие хранится в служебном каталоге кластера — по умолчанию это папка srvinfo внутри каталога программы агента сервера. В Windows типичный путь выглядит как C:\Program Files\1cv8\srvinfo (для 64-разрядной версии — C:\Program Files\1cv8\srvinfo, для 32-разрядной — C:\Program Files (x86)\1cv8\srvinfo). В Linux кластер обычно размещается в /opt/1cv8/x86_64/<версия>/srvinfo либо в каталоге, указанном при запуске агента параметром -d.

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

Отдельно существует кэш на стороне клиента — он хранится в профиле пользователя (%APPDATA%\1C\1cv8 и %LOCALAPPDATA%\1C\1cv8) и к серверному кэшу отношения не имеет. Путаница между этими двумя уровнями — типичная ошибка: администратор чистит клиентский кэш, а проблема сидит на сервере, или наоборот.

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

Каталог srvinfo — рабочая папка агента сервера 1С. В ней находится одна или несколько папок reg_<порт> — по одной на каждый кластер, зарегистрированный на данном сервере. Стандартный порт агента — 1541, поэтому чаще всего встречается имя reg_1541.

Внутри reg_1541 располагаются ключевые элементы:

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

Именно файлы в GUID-папках баз чаще всего подразумевают под «кэшем сервера», когда говорят о рассинхронизации метаданных, ошибках после обновления конфигурации или «зависших» фоновых заданиях.

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

Путь по умолчанию может быть изменён при установке или запуске агента. Надёжный способ узнать реальное расположение — посмотреть параметры запуска службы.

В Windows откройте «Службы» (services.msc), найдите службу «Агент сервера 1С:Предприятия», откройте её свойства и посмотрите строку «Исполняемый файл». Параметр -d в командной строке указывает рабочий каталог кластера — это и есть место хранения кэша. Альтернатива — реестр: ветка HKLM\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3 Server Agent, значение ImagePath.

В Linux проверьте unit-файл systemd (systemctl cat srv1cv8*) или запущенный процесс: команда ps aux | grep ragent покажет строку запуска с параметром -d.

ps aux | grep ragent  # Linux: найти параметр -d в строке запуска агента

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

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

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

Как безопасно очистить кэш сервера 1С

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

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

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

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

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

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

Проверка результата после очистки

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

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

Типичные ошибки при работе с серверным кэшем

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

FAQ