Сброс кэша сервера 1С: что чистить, а что трогать нельзя

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

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

Сначала выясните, кэш ли виноват

Тормоза бывают из-за памяти, блокировок, SQL-сервера или диска. Чистка кэша решает только часть этих причин. Потратьте десять минут на диагностику, чтобы не останавливать работу пользователей зря.

Признаки, что помогает именно сброс

• 🐢 Работа замедляется к концу недели и приходит в норму после перезагрузки сервера.
• 📈 Процессы rphost занимают в диспетчере задач гигабайты памяти и растут.
• 🧩 Новые сеансы подключаются долго, а в каталоге кластера накопились тысячи мелких папок.
• 🔁 После обновления конфигурации или платформы пользователи видят старые формы и отчёты.

Что посмотреть до остановки

1. Диспетчер задач или top: сколько памяти у каждого rphost, нет ли процесса с загрузкой процессора под 100% без видимой причины.
2. Консоль администрирования серверов 1С: раздел «Сеансы» и «Соединения». Нет ли зависших сеансов, которые держат блокировки.
3. Размер каталога кластера. Если в нём десятки гигабайт, причина понятна.
4. Свободное место на диске. Меньше 10% свободного — сначала разбирайтесь с диском.

Через командную строку то же самое можно получить утилитой rac. Она лежит рядом с ragent в каталоге bin платформы:

rac cluster list
rac session list --cluster=<идентификатор_кластера>

Если в списке сеансов много записей с давним временем последней активности, чистить нужно именно их, а не диск.

Остановка служб и завершение процессов

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

Windows

1. Предупредите пользователей и дождитесь, пока они выйдут. Либо завершите сеансы через консоль.
2. Откройте services.msc, найдите службу «Агент сервера 1С:Предприятия 8.3» и остановите её.
3. Откройте диспетчер задач и проверьте, что процессов ragent.exe, rmngr.exe и rphost.exe не осталось. Если остались, завершите их вручную.

То же командой, если название службы у вас стандартное:

net stop "Агент сервера 1С:Предприятия 8.3 (x86-64)"

Точное название зависит от версии и разрядности. Посмотрите его в services.msc.

Linux

sudo systemctl stop srv1cv83
pgrep -a "ragent|rmngr|rphost"

Имя юнита у разных установок может отличаться, обычно оно начинается с srv1cv8. Вторая команда должна ничего не вернуть.

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

Чистка каталога кластера: что удалять, а что нет

Каталог кластера по умолчанию лежит в srvinfo. На Windows это обычно папка внутри каталога установки платформы, на Linux — домашняя папка пользователя usr1cv8. Внутри есть подкаталог вида reg_1541 (номер порта главного менеджера).

Структура примерно такая:

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

Пошагово

1. Скопируйте весь srvinfo в другое место. Если места нет, хотя бы реестры 1CV8Clst.lst и 1CV8Reg.lst.
2. Откройте папку reg_1541 (у вас номер может быть другим).
3. Удалите папки snccntx… в корне кластера и в папках баз.
4. Удалите зависшие *.lck только если уверены, что служба остановлена.
5. Запустите службу и дождитесь, пока поднимутся rmngr и rphost.
6. Подключитесь к базе и проверьте основной сценарий.

⚠️ Не нужно чистить папку целиком. Если вы всё-таки удалили 1CV8Clst.lst, кластер запустится пустым. Верните файл из копии и перезапустите службу.

Временные файлы пользователя службы

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

Кэш клиента и серверные формы: если пользователи видят старое

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

• На клиенте каталог кэша находится в профиле пользователя, в папках Local и Roaming каталога 1C (внутри 1cv8). Папки с длинными именами из букв и цифр — это кэш конфигурации по базам.
• Быстрее всего чистить кэш при запуске: добавьте в строку запуска ключ /ClearCache. Ключ работает для толстого и тонкого клиента, сбрасывает локальный кэш и не трогает данные в базе.
• Если клиент подключается к серверу через веб-сервер, очистите также кэш браузера для адреса публикации.

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

Утилита chdbfl: когда она нужна, а когда бесполезна

chdbfl.exe лежит в каталоге bin платформы. Её часто советуют «заодно» после чистки. Но у неё узкая задача: проверка и исправление структуры файлового варианта базы, то есть одного файла 1Cv8.1CD.

Что это значит на практике:

• 🗂 Файловая база. Закройте все сеансы, сделайте копию файла 1Cv8.1CD, запустите chdbfl.exe, укажите файл. Отметьте «Исправлять обнаруженные ошибки» и нажмите «Выполнить».
• 🗄 Клиент-серверная база на PostgreSQL или MS SQL. Утилита здесь не работает . Структуру проверяйте средствами СУБД и тестированием в Конфигураторе («Администрирование» → «Тестирование и исправление»).

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

Лимиты памяти и перезапуск рабочих процессов

Чистка каталога даёт эффект на день-два. Устойчивый результат даёт настройка кластера, чтобы rphost перезапускались сами, пока не раздулись.

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

Примерные значения

Ориентир, не догма. Сервер с 32 ГБ памяти и двумя рабочими серверами: интервал перезапуска 86400 (сутки), допустимый объём 8388608 Кб (это ровно 8 ГБ: 8 × 1024 × 1024), интервал превышения — 300 секунд.

Если сервер один и памяти мало, ставьте порог ниже, например 4 ГБ, и следите за числом рабочих процессов. Много процессов на небольшом объёме памяти заканчивается подкачкой, и тормозит всё.

Правила, которые стоит соблюдать:

1. Меняйте один параметр за раз и наблюдайте несколько дней.
2. Перезапуск ставьте на ночное окно, а не на рабочие часы. Пользователи, чей сеанс был на закрывающемся процессе, получат разрыв соединения.
3. Не ставьте интервал перезапуска меньше часа. Переподключение сеансов само по себе нагружает сервер.

После изменения параметров перезапуск самого кластера не требуется. Настройки применяются к рабочим процессам по мере их перезапуска.

Автоматизация: ночная чистка по расписанию

Если приходится чистить кэш каждую неделю, оформите это скриптом и поручите планировщику.

Windows: скрипт и задание

Скрипт clear_srvinfo.bat для ночного окна:

net stop "Агент сервера 1С:Предприятия 8.3 (x86-64)"
timeout /t 20
for /d %%D in ("D:\srvinfo\reg_1541\snccntx*") do rd /s /q "%%D"
net start "Агент сервера 1С:Предприятия 8.3 (x86-64)"

Путь D:\srvinfo и номер reg_1541 замените на свои. Если папки snccntx… лежат и внутри каталогов баз, добавьте вторую такую же строку с путём до каталога базы.

В «Планировщике заданий» создайте задачу с запуском от имени администратора и триггером на 03:00 раз в неделю. Поставьте «Выполнять с наивысшими правами».

Linux: cron

0 3 * * 0 systemctl stop srv1cv83 && find /home/usr1cv8/.1cv8/1C/1cv8/reg_1541 -maxdepth 2 -name 'snccntx*' -exec rm -rf {} + ; systemctl start srv1cv83

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

Чего не автоматизировать

• ❌ Удаление реестров 1CV8Clst.lst и 1CV8Reg.lst.
• ❌ Запуск chdbfl с исправлением ошибок без копии базы.
• ❌ Чистку без проверки, что служба действительно остановилась: скрипт должен упасть, а не удалять файлы под работающим сервером.

Добавьте в скрипт запись в журнал: когда остановили, сколько места освободили, когда запустили. Через месяц по журналу будет видно, дала ли чистка эффект.

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

Бывает, что чистка только отнимает время. Не трогайте каталог, если:

• 🧱 тормозит одна конкретная операция, например проведение документов за месяц. Это запрос или блокировка, а не кэш;
• 🗃 СУБД забита: на SQL-сервере разросся журнал транзакций или давно не обновлялась статистика;
• 💾 на диске нет места. Чистка snccntx… освободит мегабайты, а проблема в сотнях гигабайт бэкапов;
• ⏱ проблема появляется только у одного пользователя. Скорее всего, виноват его клиентский кэш или сеть.

Мини-кейс

Сервер на 16 ГБ памяти, один кластер, 60 пользователей. К пятнице rphost вырастал до 11 ГБ, и базу было не узнать. Админ каждую неделю чистил каталог вручную и перезапускал службу. Вместо этого задал допустимый объём памяти 6 ГБ (6 × 1024 × 1024 = 6291456 Кб) и ночной перезапуск раз в сутки. Через две недели ручная чистка стала не нужна.

Если после чистки стало хуже

Бывает, что после остановки и запуска кластер не поднимается или базы не видны. Разберите типичные случаи.

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