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

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

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

Ниже разобраны практические способы очистки кэша на сервере 1С: от мягкого перезапуска рабочих процессов до ручного удаления каталогов srvinfo и reg_1541. Материал ориентирован на администраторов, работающих с кластером 1С на Windows или Linux.

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

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

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

Отдельно существует кэш на стороне клиентов: каталоги вида %APPDATA%\1C\1cv8\ и %LOCALAPPDATA%\1C\1cv8\ с папками, названными GUID базы. Если проблема проявляется только у одного пользователя, начинать нужно именно с клиентского кэша, а не с сервера.

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

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

Другой сценарий — ошибки после восстановления базы из копии, переноса базы на другой сервер или изменения настроек кластера. Также кэш чистят, когда каталог srvinfo разросся до десятков гигабайт и занимает критический объём диска.

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

Подготовка: что сделать до очистки

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

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

Также зафиксируйте текущие настройки: имя базы в кластере, параметры подключения к СУБД, рабочие порты. Это пригодится, если после очистки базу придётся заново зарегистрировать в кластере.

Способ 1: перезапуск службы агента сервера 1С

Самый простой и безопасный способ сбросить оперативный кэш рабочих процессов — перезапустить службу. На Windows это делается через оснастку «Службы»: найдите службу «Агент сервера 1С:Предприятия» и выполните перезапуск. На Linux служба обычно называется srv1cv8 и управляется через systemctl.

sudo systemctl restart srv1cv8-8.3.22-1750

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

Способ 2: удаление файлов кэша в каталоге srvinfo

Если перезапуск не помог, переходят к ручной очистке. Последовательность такова: завершите сеансы, остановите службу агента сервера, перейдите в каталог srvinfo и удалите содержимое подкаталога reg_1541 (или аналогичного по номеру порта) — за исключением файла 1CV8Clst.lst, в котором хранится реестр кластера. Затем запустите службу обратно.

Более аккуратный вариант — не удалять, а переименовать каталог reg_1541, например в reg_1541.bak. После запуска службы кластер создаст каталог заново. Если всё заработало, старую папку можно удалить; если возникли проблемы — вернуть её на место.

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

1. 1
   Завершите сеансы пользователей и регламентные задания в консоли кластера
2. 2
   Остановите службу агента сервера 1С
3. 3
   Переименуйте каталог srvinfo\reg_1541 в reg_1541.bak (или удалите его содержимое, кроме 1CV8Clst.lst)
4. 4
   Запустите службу агента сервера
5. 5
   Проверьте, что база открывается и данные на месте
6. 6
   Удалите каталог reg_1541.bak после успешной проверки

Способ 3: очистка через консоль кластера и настройки

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

Дополнительно в свойствах рабочего сервера кластера можно ограничить объём памяти рабочих процессов и настроить их автоматический перезапуск. Регулярный перезапуск rphost по расписанию (например, ночью) — распространённая практика, которая предотвращает накопление «протечек» памяти и устаревших кэшированных данных без ручного вмешательства.

Очистка кэша СУБД

Отдельно стоит упомянуть кэш на уровне СУБД (MS SQL, PostgreSQL). Его очистка — например, сброс процедурного кэша командой DBCC FREEPROCCACHE в MS SQL — требуется редко и только при диагностике проблем с планами запросов. Без чёткого понимания причин трогать кэш СУБД не нужно: после сброса все запросы будут перекомпилированы, что временно снизит производительность.

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

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

Частая ошибка — удаление всего каталога srvinfo вместе с реестром кластера. В этом случае список баз в кластере пропадает, и каждую базу приходится регистрировать заново вручную. Сами данные при этом не теряются (они в СУБД), но восстановление занимает время.

Вторая типичная ошибка — чистить только серверный кэш, когда проблема на клиенте. Если ошибка возникает у одного пользователя, удалите каталоги кэша в его профиле (%APPDATA%\1C\1cv8 и %LOCALAPPDATA%\1C\1cv8) при закрытой 1С — в большинстве случаев этого достаточно.

Часто задаваемые вопросы