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

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

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

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

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

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

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

Внутри srvinfo находятся подкаталоги вида reg_1541 (для кластера на порту 1541), reg_1540 и подобные. Именно в них хранятся файлы кэша метаданных, журналы сеансов, данные фоновых заданий и служебные файлы кластера (например, 1CV8Clst.lst — список зарегистрированных баз).

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

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

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

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

Пошаговая очистка кэша в Windows

Основной сценарий для Windows-сервера выглядит так. Откройте «Службы» (services.msc), найдите службу «Агент сервера 1С:Предприятия» нужной версии и остановите её. Дождитесь полной остановки — в диспетчере задач не должно остаться процессов ragent, rmngr и rphost.

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

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

1. 1
   Завершите сеансы пользователей и фоновые задания через консоль кластера
2. 2
   Остановите службу «Агент сервера 1С:Предприятия» и убедитесь, что процессы ragent, rmngr, rphost завершены
3. 3
   Сохраните копию файла 1CV8Clst.lst из каталога srvinfo
4. 4
   Удалите содержимое папки srvinfo\reg_1541 (каталоги и файлы кэша), не трогая саму папку и файл реестра баз
5. 5
   Запустите службу агента сервера
6. 6
   Выполните тестовый вход в базу и проверьте, что проблема устранена

Очистка кэша в Linux

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

systemctl stop srv1cv8-<версия>
cd /opt/1cv8/x86_64/<версия>/srvinfo
cp 1CV8Clst.lst /tmp/1CV8Clst.lst.bak
rm -rf reg_1541/*
systemctl start srv1cv8-<версия>

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

Альтернативные способы без полной остановки

Полная остановка кластера — не единственный вариант. Если проблема локальная (например, у одного пользователя «отвалилась» база с ошибкой потока), сначала попробуйте более мягкие меры.

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

Для клиентского кэша на компьютере пользователя очищаются каталоги %APPDATA%\1C\1cv8 и %LOCALAPPDATA%\1C\1cv8 — там лежат кэшированные метаданные по идентификаторам баз. Прежде чем останавливать сервер, убедитесь, что проблема не решается очисткой кэша на стороне клиента.

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

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

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

Профилактика: как реже чистить кэш

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

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

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

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