При обслуживании большого количества информационных баз 1С часто возникает ситуация, когда необходимо обновить несколько однотипных конфигураций до одного и того же релиза. Если базы имеют существенные доработки (нетиповые), процесс сравнения и объединения может занимать значительное время. Встает логичный вопрос: обязательно ли копировать файл обновления .cfu для каждой базы или можно запустить процессы параллельно, обращаясь к одному и тому же исходному файлу? Разберем эту ситуацию подробно, проанализировав механизмы работы платформы 1С:Предприятие.
Рассмотрим, как операционная система Windows и платформа 1С взаимодействуют с файлами во время обновления. Основное опасение администраторов связано с ошибкой "совместного доступа к файлу". Однако, проанализируем тип операции, которую выполняет Конфигуратор. При выборе файла обновления через меню Конфигурация — Поддержка — Обновить конфигурацию или при прямом выборе файла, 1С открывает .cfu исключительно в режиме Shared Read (совместное чтение).
Поскольку процесс обновления не предполагает внесения изменений в сам файл .cfu, операционная система позволяет любому количеству процессов одновременно считывать из него данные. Таким образом, технического запрета на использование одного файла обновления для нескольких запущенных экземпляров Конфигуратора не существует. Вы можете смело запускать сравнение во второй и последующих базах, указывая путь к тому же самому файлу.
Выясним, почему процессы не конфликтуют между собой в процессе самого сравнения. Важно понимать, что основная работа происходит не в папке с файлом обновления, а во временных директориях пользователя. Разберем этот процесс по шагам:
.cfu.%TEMP% или AppData\Local\Temp).Поскольку каждый запущенный экземпляр 1cv8.exe имеет свой уникальный идентификатор процесса (PID) и создает временные файлы с уникальными именами (используя GUID), потоки данных разных баз полностью изолированы друг от друга. Единственное общее звено — это исходный файл .cfu, который выступает исключительно донором данных.
Несмотря на общую стабильность метода, на практике иногда случаются кратковременные блокировки в момент инициализации чтения. Проанализируем совет опытных администраторов: не запускать процессы абсолютно одновременно в одну и ту же секунду.
Рекомендуется соблюдать небольшую паузу (около 5–10 секунд) между запуском обновления в разных базах. Рассмотрим оптимальный алгоритм:
.cfu и дождитесь появления окна с подтверждением релиза конфигурации поставщика.Такой подход гарантирует, что этапы первичного захвата файла на чтение не наложатся друг на друга, и вы избежите редких ошибок блокировки интерфейса.
Рассмотрим ситуацию с точки зрения производительности. Использование файла .cfu (обновление) требует от платформы дополнительных ресурсов на "сборку" полной конфигурации из дельты обновлений. Если вам нужно обновить, например, 10 или 20 баз, то каждый раз платформа будет выполнять одну и ту же избыточную работу по распаковке и генерации временного .cf.
Проанализируем более эффективный метод для массового обновления:
.cfu и обновите конфигурацию поставщика..cf (Конфигурация — Сохранить конфигурацию в файл...)..cf для сравнения и объединения со всеми остальными базами.В этом случае платформа не будет тратить время на предварительную сборку данных, и окно сравнения откроется значительно быстрее. Файлы .cf также можно использовать параллельно несколькими процессами без каких-либо ограничений.
Главным ограничением при одновременном сравнении нескольких баз является не доступ к файлу, а аппаратные ресурсы сервера или рабочей станции. Разберем ключевые моменты:
1. Дисковая подсистема. Если базы данных и файл обновления находятся на медленном HDD, одновременное чтение и запись огромного объема временных данных приведет к резкому росту очереди диска. В результате суммарное время двух параллельных обновлений может превысить время двух последовательных. Для комфортной параллельной работы критически важно использование SSD (NVMe).
2. Оперативная память (RAM). Процесс сравнения и объединения очень прожорлив. Для тяжелых конфигураций, таких как ERP Управление предприятием или Комплексная автоматизация, один поток Конфигуратора может потреблять от 2 до 8 Гб оперативной памяти. Если памяти станет недостаточно, система начнет использовать файл подкачки, что замедлит процесс в десятки раз. Убедитесь, что объема RAM достаточно для всех запущенных процессов.
3. Процессор (CPU). Расчет соответствий в окне сравнения — это вычислительная задача. Наличие многоядерного процессора позволит распределить нагрузку от разных экземпляров Конфигуратора по разным ядрам, что сделает работу плавной.
Посмотрим на опыт использования специализированного ПО, такого как "Обновлятор-1С". Данные инструменты поддерживают многопоточное обновление и работают по тому же принципу: они запускают несколько сеансов Конфигуратора, которые могут обращаться к одним и тем же файлам шаблонов в папке tmplts. Это еще раз подтверждает надежность метода одновременного использования файлов обновлений, если соблюдены базовые правила по распределению ресурсов и очередности запуска.
Подведем итог: запускать одновременно два и более сравнения с одним файлом .cfu можно. Это стандартная практика, которая экономит время администратора. Главное — следить за объемом свободной оперативной памяти и давать платформе небольшую "фору" в несколько секунд при старте каждого нового процесса.