При обновлении крупных конфигураций, таких как 1С:Управление торговлей 11, ERP или Комплексная автоматизация, администраторы часто сталкиваются с этапом отложенного обновления данных. Этот процесс может занимать длительное время, и логичным желанием является его ускорение за счет распараллеливания задач. Однако бездумное увеличение количества потоков может не только не ускорить процесс, но и полностью парализовать работу пользователей. В этой статье мы подробно разберем, как найти баланс между скоростью обновления и стабильностью системы.
Первым делом нам необходимо проанализировать технические ограничения самой платформы 1С:Предприятие. Существует существенная разница в том, как система работает с многопоточностью в зависимости от используемой лицензии (ПРОФ или КОРП). Рассмотрим подробнее ситуацию, когда сервер обладает значительными мощностями, например, имеет 24 физических ядра.
Если в организации используется версия ПРОФ, важно помнить о жестком ограничении, введенном начиная с версии платформы 8.3.12.1440. Сервер приложений 1С в версии ПРОФ может задействовать не более 12 ядер процессора. Даже если ваша операционная система видит 24 или 48 ядер, платформа просто не будет использовать избыточные ресурсы для выполнения рабочих процессов. В то же время версия КОРП лишена этих ограничений и позволяет масштабироваться на все доступные аппаратные мощности.
Важно различать понятия ядра процессора и потоки обновления. Как справедливо отмечают специалисты, ограничение в 12 ядер для ПРОФ-версии не означает запрет на запуск более чем 12 фоновых заданий. Вы можете запустить и 20 потоков, но все они будут конкурировать за ресурсы тех самых 12 ядер, которые «видит» платформа.
Каждый поток отложенного обновления представляет собой отдельный сеанс фонового задания. Проанализируем, сколько ресурсов потребляет один такой поток. В среднем, выполнение одной процедуры обновления в рамках фонового задания может требовать от 200 до 500 МБ оперативной памяти. Это значение сильно зависит от объема обрабатываемых данных и сложности алгоритмов, заложенных в конкретный обработчик обновления.
При планировании количества потоков выполним несложный расчет: если мы решим установить 15 потоков, нам необходимо зарезервировать под них от 4 до 8 ГБ свободной оперативной памяти. Эти ресурсы должны быть доступны сверх тех, что уже потребляются операционной системой, процессом rphost для работы текущих пользователей и SQL-сервером для кэширования данных.
Часто «узким местом» при выполнении отложенного обновления становится вовсе не процессор, а дисковая подсистема. Отложенное обновление — это всегда массированная запись и чтение данных. Проанализируем типы накопителей и их возможности:
Увеличение числа потоков не всегда дает линейный прирост скорости. Многие объекты в 1С (например, регистры накопления, таблицы расчетов или ключевые справочники) могут блокироваться при параллельной записи. Рассмотрим ситуацию: если 10 потоков одновременно пытаются внести изменения в одну и ту же таблицу, возникнут ожидания на блокировках Lock Wait. В результате реальная скорость обновления упадет, так как потоки будут большую часть времени ждать освобождения ресурсов друг другом.
Именно поэтому значение в 8 потоков часто называют «золотой серединой». Оно позволяет эффективно загрузить диск и процессор, минимизируя при этом вероятность конфликтов доступа к таблицам базы данных.
Для определения оптимального числа потоков в вашей системе, мы рекомендуем следовать следующему алгоритму:
Настроить данный параметр можно непосредственно в пользовательском интерфейсе. Путь может незначительно отличаться в зависимости от версии БСП (Библиотеки стандартных подсистем), встроенной в вашу конфигурацию:
Перейдите в раздел Администрирование (или Обслуживание) — Обновление программы — Результаты обновления. Там вы найдете гиперссылку «Настройка потоков обновления» или аналогичную. По умолчанию система может предлагать всего 1 поток, что является самым безопасным, но и самым медленным вариантом для крупных информационных баз.
Посмотрим на пример логики, которую использует система при распределении задач (упрощенно):
// Примерная схема запуска потоков в БСП
ПараметрыЗапуска = НовыеПотокиОбновления();
ПараметрыЗапуска.КоличествоПотоков = 8;
ПараметрыЗапуска.Приоритет = ПриоритетФоновыхЗаданий.Низкий;
ВыполнитьРаспределениеЗадач(ПараметрыЗапуска);
Подведем итог: Для сервера с 24 ядрами и версией ПРОФ, установка 8 потоков является наиболее взвешенным решением. Если база находится на быстрых NVMe дисках и обновление идет в нерабочее время, можно пробовать увеличить это значение до 12, внимательно наблюдая за очередями к дисковой подсистеме и блокировками в SQL.