Очистка кэша сервера 1С на Windows и Linux: порядок действий

Чтобы почистить кэш 1С сервера, остановите службу агента сервера, удалите папки snccntx* внутри каталога кластера (reg_1541 по умолчанию) и запустите службу снова. Файлы реестра кластера (1CV8Clst.lst и подобные) трогать нельзя. Вся процедура занимает 5-10 минут, но на это время все пользователи будут отключены.

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

Ниже: где что лежит, как чистить кэш сервера 1С под Windows и Linux, как поставить очистку на расписание и что делать, если после неё что-то пошло не так.

Когда чистка действительно нужна, а когда нет

Чистить кэш «на всякий случай» не стоит. Сервер сам пересоздаёт нужные файлы, но первые запуски после очистки идут медленнее, а пользователей придётся выгнать. Чистку оправдывают конкретные симптомы:

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

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

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

Где лежит кэш: пути к папкам кластера

Данные кластера хранятся в каталоге служебной информации сервера (в 1С его называют srvinfo). Внутри него для каждого кластера создаётся своя папка вида reg_<порт>. У кластера на порту 1541 это reg_1541.

Стандартные расположения:

Реальный путь мог быть изменён при установке. Как проверить:

1. Windows. Откройте оснастку «Службы», найдите «Агент сервера 1С:Предприятия 8.3», зайдите в свойства. В поле «Исполняемый файл» после ключа -d указан каталог srvinfo.
2. Linux. Выполните systemctl cat srv1cv83 (имя юнита может отличаться) или ps aux | grep ragent. В строке запуска ищите тот же ключ -d.

Внутри reg_1541 вы увидите три группы объектов:

• 📁 папки snccntx* с данными сеансов и информационных баз. Это и есть то, что можно и нужно чистить;
• 📁 папки с длинными GUID в названии: служебные данные конкретных баз;
• 📄 файлы кластера, например 1CV8Clst.lst: реестр кластера, списки баз и настройки.

Отдельно стоит помнить про временные файлы. Сервер пишет их во временный каталог пользователя, от имени которого запущена служба (на Windows это обычно USR1CV8 или системная учётная запись, на Linux /tmp и подкаталоги под usr1cv8). Их чистят отдельно, обычным удалением старых файлов.

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

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

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

Резервная копия самих информационных баз тоже нужна, если вы собираетесь делать что-то помимо удаления snccntx*. Сама по себе очистка кэша базу не затрагивает, но привычка делать выгрузку перед работами на сервере никому не вредила.

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

Порядок такой: остановили, удалили, запустили.

Вручную через оснастку «Службы»

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

Первый вход после запуска будет дольше обычного: сервер заново строит кэш. На больших базах это 1-3 минуты.

Через командную строку или PowerShell

Если сервер удалённый или вы просто не любите кликать, всё то же делается командами. В PowerShell от имени администратора:

# имя службы зависит от версии платформы и разрядности
Get-Service -DisplayName "*Агент сервера 1С*"

Stop-Service -DisplayName "Агент сервера 1С:Предприятия 8.3 (x86-64)" -Force
Get-ChildItem "C:\Program Files\1cv8\srvinfo\reg_1541" -Directory -Filter "snccntx*" |
    Remove-Item -Recurse -Force
Start-Service -DisplayName "Агент сервера 1С:Предприятия 8.3 (x86-64)"

Очистка кэша на Linux: команды и права

На Linux логика та же, отличаются имена служб и пути. Работает всё под пользователем usr1cv8, поэтому после ручных операций владелец файлов должен остаться прежним.

# 1. останавливаем агент сервера (имя юнита может содержать версию платформы)
sudo systemctl stop srv1cv83

# 2. убеждаемся, что процессы завершились
pgrep -a -u usr1cv8 'ragent|rmngr|rphost'

# 3. удаляем кэш сеансов
sudo rm -rf /home/usr1cv8/.1cv8/1C/1cv8/reg_1541/snccntx*

# 4. запускаем обратно
sudo systemctl start srv1cv83

Если на третьем шаге pgrep что-то вывел, подождите 10-20 секунд и проверьте снова. Остались висящие процессы? sudo pkill -u usr1cv8 rphost их завершит.

Типичные подводные камни на Linux:

• 🔑 запуск rm от root безопасен для удаления, но если вы что-то создавали или копировали руками, проверьте владельца: ls -l. Нужен usr1cv8:grp1cv8;
• 🧭 путь к srvinfo в вашем дистрибутиве может быть другим. Сверяйтесь с ключом -d в юните;
• 🔤 подстановка snccntx* раскрывается оболочкой. Если папок нет, команда выведет ошибку «нет такого файла». Это нормально, значит, чистить нечего.

Скрипт для автоматической очистки по расписанию

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

Windows: bat-файл и планировщик

Сохраните как clear_1c_cache.bat:

@echo off
set SRV=C:\Program Files\1cv8\srvinfo\reg_1541
set SVC=1C:Enterprise 8.3 Server Agent (x86-64)

net stop "%SVC%"
timeout /t 15 /nobreak >nul

forfiles /p "%SRV%" /m snccntx* /c "cmd /c if @isdir==TRUE rd /s /q @path" /d -7

net start "%SVC%"

Имя службы в SVC должно совпадать с тем, что показывает sc query state= all | findstr /i "1C". В русской системе отображаемое имя может быть русским, но для net stop подходит и короткое имя службы.

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

Linux: скрипт и cron

#!/bin/bash
SRV=/home/usr1cv8/.1cv8/1C/1cv8/reg_1541
systemctl stop srv1cv83
sleep 15
find "$SRV" -maxdepth 1 -type d -name 'snccntx*' -mtime +7 -exec rm -rf {} +
systemctl start srv1cv83

В crontab -e от root:

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

Это воскресенье, 03:00. Журнал /var/log/clear_1c_cache.log покажет, отработала ли задача.

Чем отличается кэш сервера от клиентского и когда чистить второй

Путаница тут частая: люди чистят кэш на сервере, а проблема сидит на рабочем месте. Различие простое.

Клиентские данные находятся в профиле пользователя, в папках 1C\1cv8 внутри AppData\Local и AppData\Roaming. Закройте 1С, удалите папки с длинными GUID-именами в этих каталогах, запустите программу снова. Список баз при этом сохранится.

Второй способ: запуск с параметром /ClearCache в ярлыке. Он очищает кэш клиента при старте, но ярлык с ним лучше использовать разово, а не постоянно: каждый запуск будет медленным.

Что делать, если после очистки что-то пошло не так

Чаще всего всё проходит тихо. Но бывают нюансы.

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

Как не допустить повторного разрастания кэша

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

• 🔄 Перезапускайте рабочие процессы по расписанию. В консоли администрирования серверов откройте настройки кластера и задайте интервал перезапуска рабочих процессов. Типичная практика: раз в сутки в ночное время, с запасом на завершение сеансов.
• 🧮 Ограничьте память процессов. Там же настраивается допустимый объём памяти рабочего процесса, после превышения которого он перезапускается. Подбирайте по фактической нагрузке: слишком маленькое значение приведёт к частым разрывам сеансов.
• 🧹 Закрывайте «мёртвые» сеансы. Сеансы, которые висят по несколько дней, закрывайте или настройте автоматическое завершение неактивных.
• 📉 Следите за размером каталога. Если reg_1541 растёт быстрее обычного, посмотрите, какие именно подпапки набирают объём. Это подскажет, база это или службы обмена.
• 💿 Держите srvinfo на быстром диске. Каталог кластера активно читается и пишется. SSD заметно разгружает сервер по сравнению с обычным жёстким диском.
• 📦 После обновления платформы перезапускайте службу агента: старые рабочие процессы не подхватят новую версию сами.

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

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