При работе с распределенными информационными базами (РИБ) системные администраторы часто сталкиваются с проблемой длительного простоя узлов во время обновления конфигурации. Ситуация, когда на обновление 15 точек уходит до 10 часов работы, является критической для бизнеса. В рамках данной статьи мы подробно разберем, как оптимизировать этот процесс, почему файлы обмена могут неоправданно раздуваться до гигабайтных размеров и какие технические приемы помогут сократить время регламентных работ в несколько раз.
Первым делом проанализируем ситуацию, описанную в теме: при обновлении типовой конфигурации 1С:Розница выгрузки в периферийные базы достигают 600–1000 Мб. Это главный "пожиратель" времени. На канале со скоростью 2 Мбит/сек передача такого объема данных занимает около 40 минут на один узел. Если узлов 15 и они обновляются последовательно, только на передачу данных уйдет 10 часов.
Важно понимать, что в норме механизм РИБ должен передавать не всю конфигурацию целиком, а только изменения (дельту). Если размер файла выгрузки (Message_XX_YY.xml) сопоставим с размером файла конфигурации (.cf), это сигнализирует о том, что в плане обмена "заклинило" регистрацию изменений конфигурации, и система каждый раз пытается отправить базу целиком.
Выясним причину такого поведения. Часто это происходит из-за некорректного завершения предыдущих обменов или программных ошибок, когда после успешного приема конфигурации периферийным узлом центральная база не получает подтверждения и продолжает считать, что конфигурацию нужно отправить. Рассмотрим подробнее, как проверить этот момент.
Если мы убедились, что конфигурация на периферийном узле уже актуальна (соответствует центральной), но обмен все равно весит сотни мегабайт, нам необходимо вручную очистить регистрацию изменений метаданных. Разберем, как это сделать программно через встроенные механизмы платформы.
Для этого в центральной базе можно воспользоваться обработкой "Регистрация изменений для обмена данными" или выполнить следующий код:
ПланОбменаСсылка = ПланыОбмена.ПоМагазинам.НайтиПоКоду("КодВашегоУзла");
ПланыОбмена.УдалитьРегистрациюИзменений(ПланОбменаСсылка, Метаданные.Конфигурация);
После выполнения этой команды система "забудет", что она должна была передать структуру базы, и в следующий файл обмена попадут только измененные данные (документы, справочники), что сократит размер файла с 700 Мб до 1–5 Мб. Это позволит мгновенно передать изменения по медленным каналам связи.
Рассмотрим стратегию "безопасного" обновления. Часто администраторы обновляют узлы по очереди, боясь, что ошибка на одной точке потребует отката всей системы. Однако, как показывает практика, время отката одной базы не сильно отличается от времени отката десяти баз, если процесс автоматизирован.
Мы рекомендуем изменить алгоритм на следующий:
Даже если 1 или 2 точки из 15 упадут с ошибкой из-за специфических данных, остальные 13 будут обновлены вовремя. Проблемные точки можно будет восстановить из бэкапа и разбираться с ними индивидуально, не задерживая работу всей сети магазинов.
Проанализируем используемый протокол передачи данных. FTP является довольно старым и не всегда эффективным протоколом для передачи больших файлов по нестабильным каналам. Рассмотрим альтернативы:
Syncthing или Resilio Sync. Эти программы работают по принципу P2P и умеют докачивать файлы при обрывах. В этом случае 1С выгружает файл в локальную папку, утилита максимально быстро раздает его на все 15 точек (используя ширину каналов всех узлов), и периферийная 1С забирает файл уже из локальной папки.Если канал связи крайне слабый и передача через РИБ постоянно сбоит, разберем метод обновления "через файл". Этот метод позволяет минимизировать риск повреждения базы при передаче больших пакетов.
Алгоритм действий:
1cv8.cf из центральной базы.Для автоматизации этого процесса на стороне периферии можно использовать параметры командной строки 1С:
"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /F "ПутьКБазе" /LoadCfg "ПутьКФайлу.cf" /UpdateDBCfg
В современных версиях 1С:Розница, построенных на базе БСП (Библиотеки стандартных подсистем), основное время занимает не просто обновление структуры, а выполнение обработчиков обновления данных (пересчет регистров, заполнение новых реквизитов).
Разберем, как ускорить этот этап. В настройках программы можно включить "Отложенное выполнение обработчиков обновления". Это позволит магазину открыться и начать продажи сразу после обновления структуры базы, а тяжелые расчеты будут выполняться в фоновом режиме, не блокируя работу пользователей. Для настройки перейдите в раздел Администрирование -> Обслуживание -> Обновление программы.
Поскольку периферийные базы являются файловыми, их производительность напрямую зависит от скорости работы диска и отсутствия помех со стороны защитного ПО. Выясним, как ускорить файловые операции:
*.1CD, *.1CL, *.log. Антивирус может замедлять процесс записи при обновлении в 2–3 раза.Подводя итог, можно сказать: основная оптимизация кроется в исправлении механизма регистрации изменений метаданных. Как только вы добьетесь того, что файл обмена будет содержать только данные, время обновления сократится с часов до минут. Параллельный запуск обновлений и использование скриптов автоматизации завершат процесс превращения ночного кошмара в отлаженный технический регламент.