Многие системные администраторы и разработчики сталкиваются с ситуацией, когда длительная операция в 1С (например, импорт огромного XML-файла обмена объемом в десятки гигабайт) выполняется часами или даже сутками, но при этом ресурсы сервера используются крайне слабо. Диспетчер задач показывает стабильную загрузку процессора на уровне ровно 25% (или еще меньше на многоядерных системах), а скорость выполнения операции оставляет желать лучшего. Разберем детально, почему так происходит, и какие существуют практические методы решения этой проблемы.
Выясняем причину: почему загружено только одно ядро?
Для начала проанализируем поведение платформы 1С при выполнении ресурсоемких задач. Ограничение в 25% загрузки процессора на четырехъядерном сервере напрямую связано с архитектурой работы приложений. Платформа «1С:Предприятие» в рамках одного сеанса (будь то клиентское приложение или фоновое задание в рабочем процессе rphost) выполняет вычисления строго в один поток.
Один поток вычислений физически не может утилизировать более одного процессорного ядра одновременно. Таким образом, несложно рассчитать итоговую загрузку процессора при работе одной тяжелой однопоточной операции:
На 4-ядерном процессоре: 1 ядро из 4 загружено на 100% = 25% общей загрузки процессора.
На 8-ядерном процессоре: 1 ядро из 8 загружено на 100% = 12.5% общей загрузки процессора.
На 36-ядерном процессоре: 1 ядро из 36 загружено на 100% = около 3% общей загрузки процессора.
В этот момент выделение системе дополнительных ядер или оперативной памяти не даст абсолютно никакого прироста производительности. Процесс обмена будет продолжать использовать ровно одно ядро процессора на максимум, пока остальные ядра простаивают.
Ограничения стандартного метода ПрочитатьИзменения()
Рассмотрим подробнее стандартный механизм планов обмена. Когда мы вызываем метод ПланыОбмена.ПрочитатьИзменения() для обработки файла (например, объемом в 23 Гб), платформа выполняет чтение XML-данных, их десериализацию и запись объектов в базу данных последовательно.
Этот процесс имеет ряд критических ограничений:
Транзакционность. Запись огромного массива данных часто происходит в рамках одной или нескольких крупных транзакций, что порождает колоссальную нагрузку на дисковую подсистему и СУБД.
Блокировки таблиц. Стандартный механизм планов обмена накладывает жесткие транзакционные блокировки на таблицы регистрации изменений. Если запустить параллельную выгрузку или загрузку в несколько потоков стандартными средствами, процессы начнут конфликтовать за доступ к таблицам регистрации, что приведет к ошибкам блокировок (lock conflicts) и взаимным блокировкам (deadlocks).
Решение 1. Повышение производительности на уровне СУБД и оборудования
Если мы не можем изменить логику самого обмена (например, конфигурация закрыта или это стандартный типовой механизм, который нельзя дорабатывать), единственным способом ускорить процесс является увеличение производительности того самого единственного потока, который выполняет задачу.
Выполним следующие шаги для системной настройки сервера:
Увеличиваем удельную мощность одного ядра. Для серверов 1С критически важна не многоядерность, а высокая тактовая частота процессора. Процессоры с частотой 4.0 ГГц и выше справятся с однопоточной задачей значительно быстрее, чем многоядерные процессоры с низкой частотой (например, 2.2 ГГц).
Настройка схемы электропитания ОС. В операционной системе сервера (Windows Server или Linux) по умолчанию может быть включен режим энергосбережения, который динамически снижает частоту процессора или «паркует» неиспользуемые ядра. Необходимо принудительно установить схему электропитания в режим «Максимальная производительность» (High Performance). Это заставит процессор работать на максимальной частоте постоянно.
Оптимизация дисковой подсистемы. Импорт больших файлов создает интенсивный поток операций чтения-записи. Убедитесь, что сам импортируемый XML-файл, файлы базы данных СУБД и базы данных временных таблиц (например, tempdb в MS SQL) расположены на быстрых твердотельных накопителях (NVMe SSD).
Настройка авторасширения файлов базы данных. Во время записи миллионов объектов СУБД постоянно увеличивает размер файлов базы данных и лога транзакций. Если шаг авторасширения установлен слишком маленьким (например, 1 Мб или 10%), СУБД будет регулярно приостанавливать транзакции для выделения места на диске. Настройте фиксированный шаг авторасширения файлов БД (например, 512 Мб или 1024 Мб).
Решение 2. Альтернативное создание узла РИБ через резервную копию
Часто гигантские файлы обмена (в десятки гигабайт) формируются при попытке создать начальный образ нового подчиненного узла распределенной информационной базы (РИБ) в крупной компании. Выгрузка и последующая загрузка такого XML-файла штатными средствами может длиться сутками и завершиться аварийно.
Рассмотрим шаг за шагом альтернативный, гораздо более быстрый и надежный способ создания подчиненного узла без использования тяжелого XML-файла:
Создание бэкапа. Делаем полную резервную копию центральной базы данных средствами СУБД (например, резервную копию .bak в MS SQL Server).
Развертывание. Восстанавливаем эту копию на сервере подчиненного узла под новым именем базы данных.
Преобразование базы в подчиненный узел. В восстановленной базе программно устанавливаем связь с главным узлом. Для этого запускаем обработку со следующим кодом:
ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаГлавныйУзел);
Где СсылкаНаГлавныйУзел — это ссылка на предопределенный элемент соответствующего плана обмена, указывающий на центральную базу.
Быстрая очистка лишних данных. Если в новом узле не требуются все исторические данные (например, документы прошлых лет), их удаление можно произвести непосредственно на уровне СУБД с помощью быстрых SQL-скриптов (командой TRUNCATE TABLE), предварительно отключив внешние ключи. Это займет считанные минуты вместо десятков часов стандартного удаления через объектную модель 1С.
Решение 3. Распараллеливание обмена через фоновые задания
Если отказаться от стандартных механизмов планов обмена в пользу собственной архитектуры импорта-экспорта, мы сможем задействовать все ядра сервера. Для этого необходимо разделить один монолитный поток на несколько независимых фоновых процессов.
Проанализируем алгоритм распараллеливания:
Разделение данных на пакеты. При выгрузке данных мы не пишем всё в один файл, а разделяем объекты по типам метаданных или диапазонам кодов (например, отдельно выгружаем справочник номенклатуры, отдельно контрагентов, отдельно документы за разные периоды времени). Каждая группа выгружается в свой файл.
Многопоточная загрузка. В базе-приемнике мы запускаем несколько параллельных фоновых заданий, каждое из которых обрабатывает свой файл. Для этого используем менеджер фоновых заданий. Платформа 1С автоматически распределит эти задания по разным рабочим процессам rphost, задействуя свободные ядра процессора.
Пример программного запуска фонового задания для параллельной обработки конкретного файла данных:
ПараметрыПроцедуры = Новый Массив;
ПараметрыПроцедуры.Добавить("C:\Exchange\Import_Part1.xml");
ФоновыеЗадания.Выполнить("МодульИнтеграции.ПрочитатьФайлОбмена", ПараметрыПроцедуры);
При реализации многопоточного обмена важно учитывать блокировки СУБД. Рекомендуется отключать проведение документов во время загрузки, перенося эту операцию на более поздний этап, и использовать транзакции небольшого размера (например, записывать объекты пакетами по 100-1000 штук в одной транзакции).
Решение 4. Переход на шины данных и событийно-ориентированный обмен
Наличие файлов обмена размером 23 Гб свидетельствует о методологической ошибке в проектировании интеграции информационных систем. Накопление критического объема изменений парализует работу баз данных при синхронизации.
Современным архитектурным стандартом является переход от пакетных обменов по расписанию к непрерывному обмену сообщениями (Event-Driven Architecture):
Использование брокеров сообщений. Интеграция систем настраивается через брокеры сообщений (например, RabbitMQ, Apache Kafka) или специализированные решения (такие как «1С:Шина»).
Микропакеты в режиме реального времени. Каждое изменение объекта в 1С мгновенно регистрируется и отправляется в очередь в виде небольшого сообщения (часто в формате JSON, который парсится платформой быстрее, чем XML).
Непрерывная фоновая загрузка. База-приемник непрерывно считывает сообщения из очереди небольшими порциями. Это полностью нивелирует пиковые нагрузки на процессор сервера и исключает ситуации, когда база «зависает» на сутки из-за обработки огромного файла изменений.