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

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

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

Ниже разобрано, где лежит кэш на сервере 1С, чем отличается кэш кластера от кэша СУБД, как выполнить очистку безопасно и как проверить, что проблема действительно решена, а не замаскирована.

Что относится к кэшу серверной базы 1С

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

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

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

На Windows по умолчанию каталог кластера расположен по пути C:\Program Files\1cv8\srvinfo (для 64-разрядной версии — C:\Program Files\1cv8\<версия> рядом, а сам srvinfo — в каталоге установки платформы или по пути, указанному при установке агента). На Linux типовой путь — /opt/1cv8/srvinfo или /var/lib/1cv8 в зависимости от дистрибутива и способа установки.

Внутри srvinfo находятся подкаталоги вида reg_1541 (номер соответствует порту кластера), reg_1540, а также файлы журнала кластера. Основная масса кэша — именно в reg_1541: там лежат каталоги с длинными именами-GUID, содержащие сеансовые данные и кэш метаданных каждой информационной базы. Если порт кластера нестандартный, имя каталога будет соответствовать вашему порту.

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

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

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

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

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

Очистка кэша кластера серверов 1С

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

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

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

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

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"

Очистка кэша на стороне СУБД

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

Более безопасная альтернатива в SQL Server — обновление статистики по конкретной базе и перестроение индексов по регламенту. В PostgreSQL аналогичные задачи решают команды VACUUM ANALYZE и настройка autovacuum; полный сброс shared buffers обычно не требуется, достаточно перезапуска службы СУБД в нерабочее время.

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

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

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

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

Как снизить потребность в ручной чистке

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

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

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