В процессе работы с платформой «1С:Предприятие 8» пользователи и администраторы часто сталкиваются с ситуацией, когда программа внезапно завершает работу. При этом в системных логах или прямо на экране появляется критическая ошибка, указывающая на превышение максимально допустимого размера внутреннего файла в каталоге vrs-cache.
Особенно парадоксально эта проблема выглядит в клиент-серверных базах данных. Казалось бы, вся информационная база хранится на мощном сервере под управлением MS SQL Server или PostgreSQL, а локальный компьютер пользователя выполняет лишь роль отображения интерфейса. Тем не менее локальный файл cache.1CD разрастается до гигантских размеров (более 4 ГБ) и приводит к аварийному завершению работы платформы. В этой статье мы подробно разберем, почему возникает эта ошибка, как устроен локальный кэш платформы и как навсегда решить эту проблему на уровне кода и администрирования.
Для начала проанализируем внутренние механизмы платформы 1С. Даже при работе в клиент-серверном варианте тонкий или толстый клиент создает на локальном диске пользователя временные служебные файлы. Они располагаются в системных каталогах профиля Windows (обычно в папке %LOCALAPPDATA%\1C\1cv8\...).
Каталог vrs-cache (Web Resource Service Cache) отвечает за кэширование клиент-серверных вызовов, метаданных форм, программных модулей, картинок и других интерфейсных элементов. Это необходимо для того, чтобы не запрашивать статичную информацию с сервера при каждом действии пользователя, разгружая сеть и ускоряя отклик интерфейса.
Файл cache.1CD — это не что иное, как база данных собственного файлового формата 1С, развернутая локально. Платформа использует СУБД-движок файловой версии для упорядоченного хранения кэшированных объектов. А раз это база данных формата 1С, на нее распространяются все стандартные технологические ограничения файлового формата:
.1CD по умолчанию ограничен 4 ГБ.Если файл кэша на компьютере конкретного пользователя раздувается до 4–5 ГБ, это явный признак технической неисправности: либо некорректно работает сама платформа, либо в конфигурации допущена логическая ошибка, забивающая кэш «мусором».
Рассмотрим практический кейс, который часто становится причиной лавинообразного роста cache.1CD. Программисты часто используют временное хранилище для вывода динамических изображений (например, фотографий номенклатуры, сканов документов или динамических диаграмм) на управляемую форму.
Выясним причину, по которой стандартный механизм работы с картинками может сломать систему. Для этого разберем типичный ошибочный код, который приводит к утечке памяти в кэш:
&НаСервере
Процедура ОбновитьКартинкуНаФормеОшибочно()
// Получаем двоичные данные картинки из базы данных
ДвоичныеДанные = ПолучитьДвоичныеДанныеКартинки();
// Помещаем во временное хранилище без привязки к уникальному идентификатору формы
АдресКартинки = ПоместитьВоВременноеХранилище(ДвоичныеДанные);
// Передаем адрес на форму в реквизит, связанный с полем картинки
ПутьККартинке = АдресКартинки;
КонецПроцедуры
Почему этот код опасен? Метод ПоместитьВоВременноеХранилище() без указания уникального идентификатора формы помещает данные в сеансовое временное хранилище. Платформа регистрирует новый временный адрес и кэширует двоичные данные в локальный файл cache.1CD.
Если этот код выполняется регулярно (например, при активизации строки в динамическом списке товаров или по обработчику ожидания каждые несколько секунд), то при каждом вызове платформа будет создавать новые адреса во временном хранилище. При этом старые адреса и связанные с ними тяжелые двоичные данные (картинки, файлы) не удаляются автоматически. Они продолжают висеть в памяти сеанса и дублироваться в локальном кэше на диске вплоть до закрытия программы пользователем. За день активной работы кэш легко преодолевает отметку в 4 ГБ, и 1С вылетает с ошибкой.
Чтобы избежать переполнения локального кэша, разработчик должен строго контролировать жизненный цикл данных во временном хранилище. Рассмотрим два надежных способа решения этой проблемы.
Самый простой и надежный способ — всегда привязывать адрес временного хранилища к уникальному идентификатору текущей управляемой формы. В этом случае платформа будет автоматически затирать предыдущие данные, зарегистрированные для этой формы по указанному адресу, а при закрытии формы полностью очистит все связанные с ней данные из кэша.
Модифицируем наш код с учетом этого правила:
&НаСервере
Процедура ОбновитьКартинкуНаФормеПравильно()
ДвоичныеДанные = ПолучитьДвоичныеДанныеКартинки();
// Передаем УникальныйИдентификатор формы третьим параметром
// Если по этому адресу уже были данные формы, они корректно перезапишутся
АдресКартинки = ПоместитьВоВременноеХранилище(ДвоичныеДанные, , ЭтаФорма.УникальныйИдентификатор);
ПутьККартинке = АдресКартинки;
КонецПроцедуры
При таком подходе локальный файл cache.1CD не будет раздуваться, так как старые версии картинок будут своевременно удаляться самой платформой.
Если нам необходимо жестко контролировать использование ресурсов (например, при обработке больших массивов файлов в цикле), мы можем принудительно очищать временное хранилище с помощью метода УдалитьИзВременногоХранилища().
Посмотрим на пример реализации такого алгоритма:
&НаСервере
Процедура ОчиститьПредыдущуюКартинку(СтарыйАдрес)
// Проверяем, что адрес действительно указывает на временное хранилище
Если ЭтоАдресВременногоХранилища(СтарыйАдрес) Тогда
Попытка
УдалитьИзВременногоХранилища(СтарыйАдрес);
Исключение
// Обработка исключения, если адрес уже недействителен
КонецПопытки;
КонецЕсли;
КонецПроцедуры
Используя этот метод, мы можем своевременно освобождать оперативную память сервера и локальный кэш пользователя, не дожидаясь окончания работы формы или завершения сеанса.
Помимо исправления ошибок в коде конфигурации, существуют административные методы, помогающие локализовать и устранить последствия разрастания кэша на рабочих станциях и терминальных серверах.
Во-первых, мы можем использовать специальный параметр запуска клиентского приложения 1С. В настройках подключения информационной базы в окне запуска в поле «Дополнительные параметры запуска» рекомендуется прописать ключ:
/ClearCache
Этот ключ заставляет платформу очищать кэш клиент-серверных вызовов при каждом запуске программы. Это предотвратит накопление «мусора» за предыдущие дни работы, хотя может незначительно увеличить время первого открытия форм в начале рабочего дня.
Во-вторых, системным администраторам рекомендуется настроить регулярную очистку временных файлов пользователей. Для этого можно использовать простейший скрипт автоматизации (батник), запускаемый при входе пользователя в систему или по расписанию. При написании такого скрипта важно удалять именно проблемные каталоги кэша, сохраняя файлы настроек окон и интерфейса пользователя.
Пример безопасного скрипта очистки кэша 1С (сохраняющего настройки пользователей):
@echo off
set localapp=%USERPROFILE%\AppData\Local\1C\1cv8
set roamingapp=%USERPROFILE%\AppData\Roaming\1C\1cv8
rem Удаляем кэш из локального профиля (где и лежит vrs-cache)
if exist "%localapp%" (
for /d %%i in ("%localapp%\*") do (
echo Cleaning folder: %%i
rmdir /s /q "%%i\vrs-cache" 2>nul
rmdir /s /q "%%i\Config" 2>nul
rmdir /s /q "%%i\ConfigSave" 2>nul
)
)
Этот скрипт точечно удаляет папки vrs-cache и конфигурационный кэш, не затрагивая файлы *.pfl в корневых каталогах баз данных, благодаря чему у пользователей не сбиваются их персональные настройки отчетов и размеры диалоговых окон.
Регулярный вылет 1С с ошибкой превышения размера файла в vrs-cache — это всегда следствие неконтролируемого накопления данных локальной СУБД клиента. В 90% случаев виной тому является некорректная работа разработчика с временным хранилищем при динамическом обновлении медиа-данных на форме.
Для предотвращения подобных сбоев придерживайтесь простых правил:
ПоместитьВоВременноеХранилище к уникальному идентификатору формы.УдалитьИзВременногоХранилища для тяжелых объектов, если они больше не нужны в сеансе./ClearCache для профилактики проблем на рабочих местах пользователей с интенсивным документооборотом.