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

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

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

Ниже разобрано, где именно хранится кэш на сервере, как его корректно удалить, какие есть альтернативы ручной чистке и как проверить, что проблема решена. Инструкции актуальны для типовой связки «сервер 1С:Предприятия 8.3 + MS SQL / PostgreSQL».

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

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

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

Чтобы точно узнать путь к srvinfo на конкретном сервере, откройте свойства службы «Агент сервера 1С:Предприятия» в оснастке services.msc и посмотрите строку запуска: параметр -d указывает рабочий каталог кластера. Это надёжнее, чем полагаться на путь по умолчанию, особенно если сервер настраивал не вы.

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

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

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

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

Классическая процедура выглядит так. Сначала завершите сеансы пользователей: это можно сделать через консоль кластера серверов (раздел «Сеансы» — удалить все) или просто попросив пользователей выйти. Затем остановите службу агента сервера 1С через services.msc или командой.

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

Остановить и запустить службу можно из командной строки с правами администратора. Имя службы зависит от версии платформы, посмотреть его можно в свойствах службы.

net stop "1C:Enterprise 8.3 Server Agent (x86-64)"
:: удаление кэша (путь подставьте свой)
rmdir /s /q "C:\Program Files\1cv8\srvinfo\reg_1541"
net start "1C:Enterprise 8.3 Server Agent (x86-64)"

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

Очистка клиентского кэша и команда /ClearCache

Даже при клиент-серверной архитектуре значительная часть кэша живёт на компьютере пользователя. Клиентский кэш хранится в профиле пользователя: в папках %APPDATA%\1C\1cv8 и %LOCALAPPDATA%\1C\1cv8. Внутри — подпапки с «говорящими» именами и каталоги с GUID информационной базы, например 5f4a3b2c-..... Именно папку с GUID проблемной базы и нужно удалить.

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

Когда чистить серверный кэш, а когда — клиентский

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

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

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

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

Профилактика: как снизить частоту проблем с кэшем

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

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

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