Очистка кэша сервера 1С 8.3 в кластере: от диагностики до автоматизации

Чтобы почистить серверный кэш 1С 8.3, остановите службу агента сервера, удалите в каталоге кластера папки snccntx* и запустите службу снова. Каталог кластера называется reg_1541 (по номеру порта) и лежит внутри srvinfo. Всё остальное в нём трогать нельзя: там живёт список баз и настройки кластера.

Делается это за 10-15 минут, но только в нерабочее время. После запуска сервер заново соберёт кэш, и первые минуты работы будут медленнее обычного. Ниже порядок действий для Windows и Linux, команды rac, автоочистка по расписанию и настройки, после которых кэш почти не раздувается.

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

Чистка не лечит всё подряд. Сначала убедитесь, что причина именно в кэше, иначе потеряете время и остановите работу людей зря.

Типичные признаки:

• 🐢 база стала медленнее без видимой причины, хотя нагрузка прежняя;
• 💾 каталог srvinfo вырос до десятков гигабайт, а баз немного;
• 🔁 после обновления платформы или конфигурации появились странные ошибки, которых нет в файловом варианте;
• 🧱 процессы rphost занимают всё больше памяти и не освобождают её;
• ❌ в журнале регистрации и в окне пользователя видны ошибки доступа к служебным файлам сеанса.

Быстрая проверка перед чисткой

Посмотрите размер каталога srvinfo и его подпапок. На Windows это сделает любой анализатор диска, на Linux хватит команды:

du -sh /home/usr1cv8/.1cv8/1C/1cv8/* | sort -h

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

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

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

Минимальный набор:

1. Права администратора на сервере (Windows) или root/доступ к пользователю usr1cv8 (Linux).
2. Окно, когда в базах никто не работает . Лучше вечер или выходные.
3. Свободное место для копии: достаточно архива всего reg_1541, обычно он небольшой.
4. Выгрузка или копия самих информационных баз. Чистка кэша их не затрагивает, но на всякий случай.

Не удаляйте весь каталог srvinfo и файл 1CV8Clst.lst. Без них кластер потеряет список баз и настройки, и придётся создавать всё заново и подключать базы по одной.

💡 Если баз много, заранее выпишите или сохраните скриншотом список баз из консоли администрирования. При ошибке вы быстро восстановите картину.

Остановка служб: в каком порядке и что с сеансами

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

Шаг 1. Закройте доступ к базам

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

Шаг 2. Завершите оставшиеся сеансы

В списке сеансов консоли выберите зависшие и завершите их. Для нескольких баз удобнее командная строка (подробности в разделе про rac ниже).

Шаг 3. Остановите службу

На Windows:

1. Нажмите Win+R, введите services.msc.
2. Найдите службу «Агент сервера 1С:Предприятия 8.3». В её имени есть версия платформы и разрядность.
3. Нажмите «Остановить». Если служб несколько (разные версии платформы), остановите ту, что владеет нужным кластером.
4. Откройте диспетчер задач и убедитесь, что не осталось процессов ragent.exe, rmngr.exe, rphost.exe.

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

На Linux:

systemctl stop srv1cv83

Имя юнита зависит от установки. Если вы запускали сервер скриптом, остановите его так, как запускали. Проверка:

ps aux | grep -E "ragent|rmngr|rphost"

Ручная очистка временных файлов на диске

Когда процессов нет, можно удалять. Работайте аккуратно: ошибка в пути здесь стоит дорого.

Что удалять

Откройте каталог кластера. Типичные пути:

• Windows: C:\Program Files\1cv8\srvinfo\reg_1541
• Linux: /home/usr1cv8/.1cv8/1C/1cv8/reg_1541

Если вы меняли порт кластера или каталог при установке, имя папки и расположение будут другими. Ориентир один: внутри лежит файл 1CV8Clst.lst и папки баз с длинными именами из букв и цифр.

Удаляйте только папки snccntx* (внутри каталога кластера и внутри папок баз). Это данные сеансов и кэш, платформа создаст их заново.

Не трогайте:

• ❌ 1CV8Clst.lst и другие файлы с расширением .lst;
• ❌ папки баз с длинными идентификаторами (в них журнал и индексы);
• ❌ каталоги 1Cv8Log и 1Cv8FTxt, пока вы не решили чистить именно журнал или индекс.

Для Linux удобно сначала посмотреть, что попадёт под удаление:

find /home/usr1cv8/.1cv8/1C/1cv8/reg_1541 -maxdepth 2 -type d -name 'snccntx*'

Если список выглядит разумно, удалите:

find /home/usr1cv8/.1cv8/1C/1cv8/reg_1541 -maxdepth 2 -type d -name 'snccntx*' -exec rm -rf {} +

На Windows можно воспользоваться поиском в проводнике по маске snccntx* внутри reg_1541 либо PowerShell:

Get-ChildItem "C:\Program Files\1cv8\srvinfo\reg_1541" -Recurse -Directory -Filter "snccntx*" | Remove-Item -Recurse -Force

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

Рабочие процессы пишут временные файлы в папку Temp учётной записи, под которой запущена служба. Для Windows это обычно профиль локальной системы или отдельного пользователя usr1cv8, для Linux это /tmp и подкаталоги пользователя usr1cv8. После аварий там копятся файлы с расширением .tmp и папки с именами в виде идентификаторов.

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

Запуск и проверка

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

Команда rac: чистим и управляем кластером без интерфейса

Утилита rac лежит в каталоге платформы рядом с ragent (в Windows rac.exe). Она работает с агентом администрирования ras или напрямую с агентом сервера. Для автоматизации это единственный нормальный путь.

Запустите сервер администрирования, если он ещё не запущен:

ras cluster --port=1545

Дальше все команды выполняются из другого окна. Сначала узнайте идентификатор кластера:

rac cluster list

В выводе будет поле cluster с UUID. Он понадобится во всех командах ниже, ниже он записан как <ID_КЛАСТЕРА>.

Полезные команды

Если в кластере включена авторизация администратора, добавьте параметры --cluster-user и --cluster-pwd. Для баз с отдельной аутентификацией есть параметры --infobase-user и --infobase-pwd. Точный набор ключей смотрите в справке: rac help и rac session help.

Что rac не умеет

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

💡 Хорошая связка для скрипта: через rac завершить все сеансы базы, остановить службу, удалить папки, запустить службу. Именно её мы и ставим на расписание.

Автоочистка по расписанию

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

Скрипт для Linux и cron

Создайте файл /usr/local/bin/clean_1c_cache.sh:

#!/bin/bash
LOG=/var/log/clean_1c_cache.log
DIR=/home/usr1cv8/.1cv8/1C/1cv8/reg_1541

echo "$(date) start" >> "$LOG"
systemctl stop srv1cv83
sleep 10
pkill -u usr1cv8 rphost
pkill -u usr1cv8 rmngr

find "$DIR" -maxdepth 2 -type d -name 'snccntx*' -exec rm -rf {} + >> "$LOG" 2>&1

systemctl start srv1cv83
echo "$(date) done" >> "$LOG"

Сделайте файл исполняемым командой chmod +x и добавьте задание в crontab -e, например на воскресенье в 03:30:

30 3 * * 0 /usr/local/bin/clean_1c_cache.sh

Планировщик заданий Windows

Для Windows сохраните команды в файл clean_1c_cache.bat: остановка службы (net stop с точным именем службы), пауза, удаление папок через PowerShell из примера выше, запуск службы (net start). Затем в «Планировщике заданий» создайте задачу:

1. Триггер: еженедельно, воскресенье, 03:30.
2. Действие: запуск .bat файла.
3. Параметры: «Выполнять с наивысшими правами», учётная запись с правами администратора.

Точное имя службы возьмите из services.msc, поле «Имя службы» в свойствах.

Регламентные задания самой базы

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

Настройки кластера: чтобы кэш не раздувался снова

После чистки полезно настроить рабочие процессы, иначе через пару месяцев всё вернётся. Настройки открываются в консоли администрирования: правый клик по рабочему серверу, «Свойства».

Что обычно подкручивают:

• ⏱ Интервал перезапуска рабочих процессов. По умолчанию процесс не перезапускается, пока его не остановить. Значение порядка 86400 секунд (раз в сутки) заставляет rphost освобождать накопленное.
• 🧠 Допустимый объём памяти рабочих процессов. При превышении сервер планирует перезапуск процесса. Ориентируйтесь на объём ОЗУ минус запас под систему и СУБД.
• 📉 Допустимое отклонение количества ошибок. Позволяет отсеивать нестабильные процессы.
• 🔢 Количество информационных баз на процесс. Для крупных баз выгодно выделить отдельный процесс, чтобы одна база не тянула остальные.

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

Что ещё сделать

• Обновите платформу до актуального релиза ветки 8.3: часть утечек памяти исправляется именно там.
• Проверьте, что антивирус не сканирует каталог srvinfo в реальном времени. Это и тормозит сервер, и портит файлы кэша.
• Держите журнал регистрации в разумных пределах: выгружайте старые записи и сокращайте срок хранения.
• Разместите srvinfo на быстром диске (SSD). Кэш активно читается и пишется.

Если не помогло: что проверить дальше

Кэш почистили, а медленно по-прежнему? Значит, причина в другом. Проверьте по порядку.

1. СУБД. Для клиент-серверной базы запросы выполняет SQL-сервер. Устаревшая статистика, раздутые логи транзакций и фрагментированные индексы тормозят работу сильнее любого кэша.
2. Блокировки. Откройте анализ блокировок и ожиданий в консоли. Длинные транзакции в одной базе легко парализуют всех.
3. Сеть. Задержка между клиентами и сервером заметна в базах с «болтливыми» обработками.
4. Железо. Нехватка ОЗУ ведёт к свопу, и тогда медленно всё. Посмотрите загрузку памяти и диска во время жалоб.
5. Конкретная операция. Если тормозит один отчёт, поможет технологический журнал и разбор запроса, а не чистка сервера.

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