Три уровня кэша в связке 1С и MS SQL Server: что чистить, в каком порядке и чем это грозит

Почистить кэш 1С на SQL-сервере — это три разные операции: удалить папки с GUID-именами в профиле пользователя на клиенте, удалить каталоги snccntx* на сервере 1С при остановленной службе и сбросить буферы и планы запросов командами DBCC в MS SQL Server. Частая ошибка — начинать с SQL: сброс кэша СУБД почти никогда не лечит «кривые» формы и зависания, а вот на полчаса замедляет всю базу.

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

Какой кэш виноват: короткая диагностика до чистки

Прежде чем что-то удалять, определите уровень. Симптомы у них разные.

Локальный кэш 1С на компьютере пользователя

Тонкий и толстый клиент хранят кэш метаданных и форм в профиле Windows. Для каждой информационной базы создаётся своя папка с именем-GUID, например a3f1c2d4-5b6e-4f70-8a9b-0c1d2e3f4a5b.

Где лежат папки:

• 📁 %APPDATA%\1C\1cv8\ — роуминговый профиль;
• 📁 %LOCALAPPDATA%\1C\1cv8\ — локальный профиль, обычно здесь основной объём.

Вставьте путь в адресную строку Проводника — переменная раскроется сама.

Ручная очистка

1. Закройте все окна 1С у пользователя. Проверьте в диспетчере задач, что не осталось процессов 1cv8c.exe и 1cv8.exe.
2. Откройте %LOCALAPPDATA%\1C\1cv8\ и удалите все папки с GUID-именами.
3. То же сделайте в %APPDATA%\1C\1cv8\.
4. Запустите базу. Первый вход займёт заметно больше времени: платформа заново скачает метаданные.

Файлы *.pfl в корне 1cv8 хранят локальные настройки клиента. Их удаление сбросит, например, размеры окон и последние выбранные значения. Трогайте их, только если чистка папок не помогла.

Очистка через параметр запуска

Если не хочется лазить по профилю, у платформы есть ключ /ClearCache. Он чистит кэш именно той базы, которую запускают.

1. В окне запуска выделите базу и нажмите Изменить.
2. Пройдите до последней страницы мастера.
3. В поле Дополнительные параметры запуска впишите /ClearCache.
4. Нажмите Готово и запустите базу.

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

Чистим кэш на сервере 1С:Предприятия

Сервер 1С хранит сеансовые данные в каталогах snccntx<GUID> внутри каталога реестра кластера. Именно их «отравление» после обновления конфигурации даёт массовые ошибки у всех пользователей.

Где искать на Windows:

C:\Program Files\1cv8\srvinfo\reg_1541\snccntx*

Каталог srvinfo мог быть указан при установке иначе. Точный путь виден в свойствах службы агента сервера: строка запуска содержит параметр -d "...\srvinfo". На Linux при установке по умолчанию путь обычно такой: /home/usr1cv8/.1cv8/1C/1cv8/reg_1541/.

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

Порядок действий

1. Убедитесь, что пользователи вышли. В консоли администрирования серверов откройте базу и посмотрите список сеансов.
2. Остановите службу «Агент сервера 1С:Предприятия 8.3». Подождите, пока в диспетчере задач исчезнут процессы ragent.exe, rmngr.exe и rphost.exe.
3. Откройте srvinfo\reg_1541\ и удалите только каталоги, чьё имя начинается с snccntx.
4. Запустите службу. Подождите 1–2 минуты, пока поднимутся рабочие процессы.
5. Войдите в базу и проверьте, ушла ли ошибка.

Сам кластер и базы в SQL от такой чистки не страдают. Данные пользователей хранятся в СУБД, а не в srvinfo.

Мягкая альтернатива: перезапуск рабочих процессов

Если сервер 1С разрастается по памяти и начинает тормозить к вечеру, полная остановка не обязательна. В консоли администрирования в свойствах кластера есть параметры Интервал перезапуска и Допустимый объём памяти. Кластер сам поднимает новый рабочий процесс и переводит на него соединения, а старый завершает.

Это не очистка snccntx, но часто снимает ту же проблему без простоя.

Кэш MS SQL Server: буферы, планы запросов, системный кэш

SQL Server держит в памяти два основных кэша:

• 💾 буферный пул — страницы таблиц, прочитанные с диска;
• 🧠 процедурный кэш — скомпилированные планы выполнения запросов.

Сбрасывать буферный пул в рабочей базе почти никогда не нужно. После сброса все запросы идут на диск, и первые 10–30 минут база работает заметно медленнее. Полезен он в основном для тестов: замерить запрос «на холодную».

Процедурный кэш сбрасывают чаще. Типичная причина — устаревшая статистика: SQL Server построил план под маленькую таблицу, таблица выросла, а план остался.

Команды очистки

Выполняйте в SQL Server Management Studio под учётной записью с правами sysadmin.

-- 1. Записать изменённые страницы на диск, иначе DROPCLEANBUFFERS их не сбросит
CHECKPOINT;

-- 2. Сбросить чистые страницы буферного пула (весь сервер!)
DBCC DROPCLEANBUFFERS;

-- 3. Сбросить все планы выполнения на сервере
DBCC FREEPROCCACHE;

-- 4. Сбросить прочие системные кэши
DBCC FREESYSTEMCACHE ('ALL');

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

Сброс планов только для одной базы

На SQL Server 2016 и новее можно очистить процедурный кэш одной информационной базы:

USE [buh_prod];
ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE;

Замените buh_prod на имя базы в СУБД. Его видно в консоли администрирования серверов 1С в свойствах информационной базы, поле База данных.

Сначала статистика, потом кэш

Сброс планов без обновления статистики даёт эффект на день-два: SQL Server построит тот же плохой план по той же старой статистике. Правильная связка:

USE [buh_prod];
EXEC sp_updatestats;
GO
ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE;

sp_updatestats обновляет только ту статистику, где были изменения. Для полного пересчёта используют UPDATE STATISTICS с выборкой WITH FULLSCAN по отдельным таблицам — дольше, но точнее.

Чистка по расписанию: SQL Agent и планировщик Windows

Регламентные задания самой 1С кэш платформы и СУБД не чистят — это делается средствами Windows и SQL Server.

Обслуживание SQL Server

Создайте план обслуживания или задание SQL Server Agent с двумя шагами:

1. Обновление статистики по базам 1С — каждую ночь.
2. Шаг T-SQL со сбросом процедурного кэша — сразу после первого.

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

Буферный пул по расписанию не сбрасывают. Это только вредит.

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

Если массовые ошибки после ночного обновления конфигурации повторяются, чистку snccntx можно автоматизировать скриптом PowerShell в планировщике заданий:

$svc = Get-Service | Where-Object { $_.DisplayName -like '1C:Enterprise 8.3 Server Agent*' }
Stop-Service -InputObject $svc -Force
Start-Sleep -Seconds 30
Get-Process rphost, rmngr -ErrorAction SilentlyContinue | Stop-Process -Force
Get-ChildItem 'C:\Program Files\1cv8\srvinfo\reg_1541' -Directory -Filter 'snccntx*' |
    Remove-Item -Recurse -Force
Start-Service -InputObject $svc

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

Скрипт для клиентских компьютеров

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

@echo off
tasklist /fi "imagename eq 1cv8c.exe" | find /i "1cv8c.exe" >nul && (
  echo Закройте 1С и запустите снова
  pause
  exit /b
)
for /d %%D in ("%LOCALAPPDATA%\1C\1cv8\*-*") do rd /s /q "%%D"
for /d %%D in ("%APPDATA%\1C\1cv8\*-*") do rd /s /q "%%D"

Маска *-* выбирает только папки с GUID-именами: в них есть дефисы. Служебные каталоги без дефиса остаются на месте. Сохраните файл в кодировке OEM 866, иначе русский текст в окне будет нечитаемым.

Как понять, что чистка помогла

Без замеров «стало быстрее» — ощущение. Снимите цифры до и после.

Замер на стороне 1С

• ⏱ Засеките время конкретной операции: формирование отчёта, проведение документа. Лучше трижды.
• 🔍 Включите замер производительности в конфигураторе или в режиме предприятия через Главное меню → Функции для технического специалиста, если эта функция включена. Он покажет, какая строка кода тормозит.
• 📜 Для глубокого разбора настраивают технологический журнал через файл logcfg.xml с событиями DBMSSQL: там видно длительность каждого запроса к SQL.

Замер на стороне SQL Server

Сколько памяти буферного пула занимает каждая база:

SELECT DB_NAME(database_id) AS db,
       COUNT(*) * 8 / 1024 AS buffer_mb
FROM sys.dm_os_buffer_descriptors
GROUP BY database_id
ORDER BY buffer_mb DESC;

Сколько места в кэше занимают планы и сколько из них использованы один раз:

SELECT objtype,
       COUNT(*) AS plans,
       SUM(CAST(size_in_bytes AS bigint)) / 1024 / 1024 AS size_mb,
       SUM(CASE WHEN usecounts = 1 THEN 1 ELSE 0 END) AS single_use
FROM sys.dm_exec_cached_plans
GROUP BY objtype
ORDER BY size_mb DESC;

Как долго страница живёт в памяти:

SELECT cntr_value AS page_life_expectancy_sec
FROM sys.dm_os_performance_counters
WHERE counter_name = 'Page life expectancy'
  AND object_name LIKE '%Buffer Manager%';

Как читать результат:

• 📉 Сразу после DROPCLEANBUFFERS значение Page life expectancy падает почти до нуля — это нормально. Если и через час оно держится на десятках секунд, серверу просто не хватает памяти.
• 📦 Тысячи планов с usecounts = 1 — признак того, что кэш забит одноразовыми запросами. Для 1С это типично из-за динамически собираемых запросов и само по себе не повод чистить кэш каждый час.
• ✅ Помог сброс процедурного кэша, но через несколько дней проблема вернулась — значит, дело в статистике. Учащайте её обновление.

Проверьте лимит памяти SQL Server

Если SQL Server и сервер 1С стоят на одной машине, а max server memory не задан, СУБД заберёт почти всю оперативную память. Тогда сервер 1С начнёт тормозить, и кажется, что «надо почистить кэш». Лечится лимитом:

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'max server memory (MB)', 24576;
RECONFIGURE;

Пример для сервера с 32 ГБ: 24 ГБ отдали SQL Server, 8 ГБ остаются системе и процессам 1С. Подберите значение под свою нагрузку.

Ошибки, после которых становится хуже

• ❌ Удалили весь каталог srvinfo или reg_1541. Кластер теряет список баз и настройки. Восстанавливать придётся из резервной копии этого каталога или регистрировать базы заново, с повторным вводом параметров подключения к SQL.
• ❌ Сбросили буферный пул днём. Все пользователи всех баз на сервере получают провал скорости на десятки минут.
• ❌ Поставили DBCC FREEPROCCACHE в задание каждый час. SQL Server постоянно перекомпилирует запросы, растёт нагрузка на процессор.
• ❌ Оставили /ClearCache в параметрах запуска. Каждый вход превращается в долгую загрузку метаданных.
• ❌ Чистили клиентский кэш при открытой 1С. Часть файлов заблокирована, папка удаляется не полностью, а ошибка остаётся.
• ❌ Удалили ibases.v8i вместе с кэшем. Список баз пропал — его придётся собирать заново или восстанавливать из копии.

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