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

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

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

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

Что именно считается кэшем на сервере 1С

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

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

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

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

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

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

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

Второй шаг — резервная копия каталога srvinfo. Это не копия баз данных, а страховка реестра кластера: если после чистки что-то пойдёт не так, вы вернёте список баз и настройки кластера за минуту. Скопируйте папку целиком в соседний каталог до остановки службы или сразу после — но до удаления чего-либо.

Очистка кэша на Windows-сервере

На Windows служба агента называется «Агент сервера 1С:Предприятия» (1C:Enterprise Server Agent). Остановить её можно через services.msc или командной строкой с правами администратора. После остановки удалите содержимое папки reg_1541, кроме файла реестра кластера, либо переименуйте папку — сервер создаст новую при запуске.

net stop "1C:Enterprise 8.3 Server Agent"
ren "C:\Program Files\1cv8\srvinfo\reg_1541" reg_1541_old
net start "1C:Enterprise 8.3 Server Agent"

Имя службы зависит от версии платформы — проверьте точное название в services.msc. Если в каталоге srvinfo несколько папок вида reg_1541, reg_1591, значит, когда-то создавались дополнительные кластеры — чистить нужно ту, что соответствует рабочему порту.

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

Очистка кэша на Linux-сервере

На Linux логика та же: остановить службу, почистить каталог, запустить. Служба обычно называется srv1cv83 (для платформы 8.3) и управляется через systemctl. Путь к srvinfo зависит от способа установки — чаще это /opt/1cv8/x86_64/8.3.xx.xxxx или домашний каталог пользователя usr1cv8.

systemctl stop srv1cv83
mv /home/usr1cv8/.1cv8/1cv8/srvinfo/reg_1541 /home/usr1cv8/.1cv8/1cv8/srvinfo/reg_1541.bak
systemctl start srv1cv83

После запуска проверьте, что служба поднялась: systemctl status srv1cv83 и список процессов ragent, rmngr, rphost через ps aux | grep 1cv8. Если rphost не появился — смотрите логи службы, чаще всего проблема в правах на каталог после ручных операций от root.

Очистка через консоль кластера и альтернативы

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

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

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

Самая частая ошибка — удаление файлов при работающей службе. Вторая — удаление всего srvinfo целиком, включая реестр кластера, после чего список баз в консоли пуст и базы приходится регистрировать заново вручную. Третья — чистка серверного кэша, когда проблема на клиенте: если ошибка возникает только у одного пользователя, начинать нужно с его локального кэша в %APPDATA%\1C\1cv8.

После запуска службы проверьте три вещи: служба работает и процессы ragent/rmngr/rphost запущены; в консоли кластера виден полный список информационных баз; пользователи подключаются без ошибок. Подключитесь к каждой проблемной базе сами и выполните типовую операцию, которая раньше вызывала ошибку.

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