Чистим кэш сервера 1С на Windows и Linux без потери баз

Серверный кэш 1С чистится удалением временных каталогов snccntx* в папке кластера при остановленной службе «Агент сервера 1С:Предприятия 8.3». Чистить можно целиком весь кластер, одну базу или только клиентский кэш на рабочих местах. Что выбрать, зависит от симптома.

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

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

Чистка не лечит всё подряд. Она помогает в узком наборе случаев.

• 🐢 После обновления платформы или конфигурации форма открывается со старым видом или падает с ошибкой.
• 🧩 Пользователи видят разные версии одной и той же формы.
• 💥 Рабочий процесс rphost вырос до десятков гигабайт и не отдаёт память.
• 🔒 Остались «зависшие» сеансы и блокировки, которые не снимаются из консоли.
• 📦 Каталог кластера разросся: сотни гигабайт в snccntx* на сервере с 40 ГБ диска.

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

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

Что подготовить до остановки службы

Подготовка занимает минут десять и страхует от неприятностей.

1. Найдите каталог кластера. В консоли администрирования серверов откройте свойства кластера или посмотрите параметры запуска службы. По умолчанию это подпапка reg_1541 внутри каталога srvinfo.
2. Предупредите пользователей и дождитесь, пока все выйдут. Список сеансов — в консоли серверов, ветка «Сеансы».
3. Сделайте копию каталога кластера или хотя бы выгрузите базу в .dt. Файлы списков кластера восстановить сложно.
4. Убедитесь, что на диске есть место для копии.

Если базы файловые, а не клиент-серверные, этот материал вам не нужен. У файловой базы нет серверного кэша: всё лежит в каталоге самой базы и в клиентских профилях.

Мягкие способы: без остановки службы

Эти варианты не требуют выключать сервер целиком. Попробуйте их первыми.

Перезапуск рабочих процессов

В консоли серверов откройте «Рабочие серверы» и найдите процессы rphost. Их можно отключить принудительно: кластер поднимет новые. Пользователи при этом потеряют сеанс, но ждать полной остановки службы не надо.

Это сбрасывает память процесса и часть оперативных кэшей. Каталоги на диске остаются нетронутыми.

Завершение зависших сеансов

В ветке «Сеансы» отсортируйте список по потреблению памяти или по времени последней активности. Сеансы, которые висят часами без вызовов, завершайте вручную. Это снимает и «призрачные» блокировки.

Плановый перезапуск процессов в настройках кластера

В свойствах кластера есть параметры перезапуска рабочих процессов: интервал и допустимый объём памяти. Типичное значение интервала — 3600 секунд (час). Для нагруженных баз его ставят на ночь или на окно с минимальной активностью, чтобы процессы не перезапускались в разгар дня.

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

Полная очистка делается при остановленной службе. Порядок такой.

1. Откройте оснастку «Службы» (services.msc).
2. Найдите службу «Агент сервера 1С:Предприятия 8.3» (в названии может быть разрядность, например x86-64). Остановите её.
3. Убедитесь в диспетчере задач, что процессов ragent, rmngr и rphost не осталось. Если висят — завершите вручную.
4. Откройте каталог кластера (...\srvinfo\reg_1541).
5. Удалите все папки, имена которых начинаются на snccntx.
6. Запустите службу обратно.

То же в командной строке от администратора. Название службы подставьте своё: посмотреть его можно командой sc query state= all | findstr /i 1c.

net stop "1C:Enterprise 8.3 Server Agent (x86-64)"
taskkill /F /IM rphost.exe
taskkill /F /IM rmngr.exe
for /d %%i in ("D:\srvinfo\reg_1541\snccntx*") do rd /s /q "%%i"
net start "1C:Enterprise 8.3 Server Agent (x86-64)"

Путь D:\srvinfo здесь условный. Подставьте свой каталог и проверьте его глазами до запуска скрипта.

Не удаляйте файлы 1CV8Clst.lst, srvribrc.lst и папки с именем-GUID. Первый хранит список баз кластера, вторые содержат журнал регистрации и служебные данные баз.

После запуска службы первые пять-десять минут сервер будет работать медленнее: кэш строится заново. Это нормально.

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

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

/home/usr1cv8/.1cv8/1C/1cv8/reg_1541

Служба обычно называется srv1cv83 (для платформы 8.3). Если вы ставили сервер нестандартно, проверьте unit-файл через systemctl list-units | grep 1c.

sudo systemctl stop srv1cv83
pgrep -a rphost
sudo find /home/usr1cv8/.1cv8/1C/1cv8/reg_1541 -maxdepth 1 -type d -name 'snccntx*' -exec rm -rf {} +
sudo systemctl start srv1cv83

Команда pgrep между остановкой и чисткой нужна, чтобы убедиться, что ничего не осталось. Если процессы живы, завершите их pkill -9 rphost.

Проверьте владельца каталога после чистки: служба работает от пользователя usr1cv8. Если вы запускали rm от root, права на сам каталог кластера остались прежними, но любые файлы, которые вы создали вручную, будут принадлежать root.

Очистка кэша одной базы, а не всего кластера

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

Через консоль администрирования

1. В консоли серверов найдите нужную базу.
2. Завершите все её сеансы.
3. Включите в свойствах базы блокировку начала сеансов, чтобы никто не зашёл во время работы.
4. Перезапустите рабочие процессы кластера. Часть кэша сбросится.
5. Снимите блокировку.

Это не стирает каталоги на диске, но решает большинство проблем с «залипшими» формами в одной базе.

Через клиентский кэш пользователей

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

1. Закройте 1С у пользователя.
2. Удалите папки с GUID из этих двух каталогов. Файл ibases.v8i (список баз) оставьте, иначе пользователю придётся заново добавлять информационные базы.
3. Откройте базу. Кэш построится заново.

Ярлык с параметром запуска /ClearCache делает то же самое автоматически при старте клиента.

"C:\Program Files\1cv8\common\1cestart.exe" ENTERPRISE /S "server\base" /ClearCache

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

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

Нужна ли плановая чистка? Для большинства серверов нет: платформа сама управляет временными каталогами. Автоматизация имеет смысл, если сервер нагружен, кластер раздувается за неделю на десятки гигабайт, а ночью нет пользователей.

На Windows используйте планировщик заданий. На Linux — cron или таймер systemd. Запускайте скрипт из предыдущих разделов раз в неделю в окно, когда никто не работает . Вот пример записи в cron для воскресенья, 04:00:

0 4 * * 0 /usr/local/bin/clear_1c_cache.sh >> /var/log/clear_1c_cache.log 2>&1

В скрипте стоит предусмотреть три вещи:

• 🛑 проверку, что в кластере нет активных сеансов (иначе скрипт завершается без действий);
• 📝 запись в лог размера каталога до и после;
• 🔔 уведомление администратору, если служба не поднялась.

Без проверки сеансов автоматическая остановка службы однажды совпадёт с закрытием периода у бухгалтеров.

Как проверить, что очистка сработала

Проверка укладывается в пять минут.

1. Размер каталога кластера. Сравните с цифрой до чистки. Для сервера, где работали месяцы без чистки, типично уменьшение в разы.
2. Откройте базу тем пользователем, у которого была проблема. Форма должна открыться в актуальном виде.
3. В консоли серверов проверьте, что рабочие процессы стартовали и потребление памяти на старте небольшое (сотни мегабайт, а не гигабайты).
4. Посмотрите журнал регистрации и технологический журнал, если он включён: нет ли ошибок обращения к кэшу.

Если через сутки размер каталога снова вырос до прежнего, проблема не в кэше. Ищите утечку в самой конфигурации: длинные запросы, обработки с накоплением данных в сеансе, неосвобождаемые объекты.

Если не помогло

• 🔁 Перезагрузите весь сервер. Иногда зависает драйвер диска или антивирус блокирует файлы 1С.
• 🛡 Добавьте каталог кластера в исключения антивируса: он часто тормозит чтение временных файлов.
• 🧪 Создайте тестовую копию базы на этом же сервере. Если там всё работает, проблема в самой рабочей базе, а не в кэше.
• 🧰 Запустите «Тестирование и исправление» для информационной базы (с копией базы на руках).
• 🔄 Проверьте, что версии платформы на клиенте и сервере согласованы по номеру сборки.

Как понять, что раздулось именно на сервере

Прежде чем что-то удалять, найдите самые тяжёлые каталоги. На Windows откройте свойства папки кластера и сравните размеры подпапок. На Linux хватит одной команды:

sudo du -sh /home/usr1cv8/.1cv8/1C/1cv8/reg_1541/* | sort -h | tail -n 15

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

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

Что не нужно делать при очистке

Каждая из этих ошибок встречается на практике.

• ❌ Удалять каталог кластера целиком «заодно». Кластер потеряет список баз.
• ❌ Чистить при работающей службе: файлы заблокированы, часть удалится, часть нет, и кэш станет противоречивым.
• ❌ Удалять каталоги баз с GUID, думая, что это кэш. Там журнал регистрации, и его не вернуть.
• ❌ Чистить клиентский кэш на сервере терминалов, не проверив, кто сейчас в сеансе: профили пользователей общие по пути, но у каждого свой.