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

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

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

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

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

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

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

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

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

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

Внутри srvinfo находятся подпапки вида reg_1541, reg_1542, reg_1543 — по одной на каждый порт рабочих процессов кластера. Именно в них лежит кэш метаданных и сеансовые данные. Также в srvinfo есть файлы 1CV8Clst.lst и 1CV8Clst.lck — это реестр кластера со списком баз и настройками. Эти файлы удалять нельзя, иначе пропадут зарегистрированные информационные базы в консоли кластера.

На Linux каталог сервера обычно находится в /opt/1cv8/... или в домашнем каталоге пользователя, под которым запущен агент (часто /home/usr1cv8/.1cv8/1C/1cv8/). Логика та же: ищем папки reg_* внутри каталога кластера.

Пошаговая очистка кэша на сервере

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

1. 1
   Завершите активные сеансы через консоль кластера или предупредите пользователей
2. 2
   Остановите службу «Агент сервера 1С:Предприятия» (services.msc или net stop)
3. 3
   Перейдите в каталог srvinfo и найдите папки reg_1541, reg_1542 и т.д.
4. 4
   Удалите содержимое этих папок или переименуйте их (например, в reg_1541.old)
5. 5
   Не трогайте файлы 1CV8Clst.lst и 1CV8Clst.lck
6. 6
   Запустите службу агента сервера обратно
7. 7
   Проверьте вход в базу — первый запуск будет дольше обычного

Остановить службу можно через оснастку «Службы» (services.msc) или командой из командной строки с правами администратора:

net stop "1C:Enterprise 8.3 Server Agent" && net start "1C:Enterprise 8.3 Server Agent"

Более безопасная альтернатива удалению — переименовать папки reg_* вместо удаления. Если после перезапуска что-то пойдёт не так (что маловероятно, но возможно в нестандартных конфигурациях), можно вернуть старые папки обратно. Через несколько дней стабильной работы переименованные папки удаляют окончательно.

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

Очистка кэша на клиентских компьютерах

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

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

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

Альтернатива: очистка без остановки сервера

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

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

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

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

Как проверить, что очистка помогла

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

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