SSIS Balanced Data Distributor - Увеличьте количество операций?

Question

В соответствии с прилагаемым, у нас есть сбалансированный дистрибьютор данных, настроенный в преобразовании данных, охватывающий около 2 миллионов строк. Задачи сценария идентичны - каждый открывает соединение с оракулом и выполняет сначала удаление, а затем вставку. (Это не относится, но это делается таким образом из-за проблем параметров с помощью команды Ole DB и поставщика Microsoft OLE DB для Oracle ...)

Проблема Я бегу в нет важно, насколько я делаю свои буферы или сколько одновременных исполнений я настраиваю, BDD не будет выполнять более пяти одновременных процессов за раз.

Я оттянул сотни тысяч строк в более крупном буфере, и он просто делится на 5 путей. Я пробовал это на нескольких машинах - текущий снимок с 16-ядерного сервера с -1 параллельными исполнениями, настроенными на пакете, - и независимо от того, что это всегда 5 параллельных заданий.

5 лучше, чем 1, но с 2,5 миллионами строк для вставки/обновления, 15 строк в секунду при 5 одновременных выполнениях не намного лучше, чем 2-3 строки в секунду с 1 одновременным выполнением.

Могу ли я заставить BDD использовать больше путей, и если да, то как?

Answer 1

Короткий ответ:

Да BDD может использовать более пяти путей. Вы не должны делать ничего особенного, чтобы заставить его, по определению, он должен автоматически сделать это за вас. Тогда почему он не использует более 5 путей? Поскольку ваш источник производит данные быстрее, чем ваш пункт назначения может потреблять вызывающее противодавление. Чтобы решить эту проблему, вы должны настроить компоненты назначения.

Длинный ответ:

В теории «по БДД принимает входные данные и направляет его в равных пропорциях, это выход, однако многие есть.» В вашей настройке имеется 10 выходов. Таким образом, входные данные должны быть одинаково распределены на все 10 выходов одновременно, и вы должны увидеть 10 путей, выполняемых одновременно - опять же в теории.

Но другая концепция BDD - «вместо маршрутизации отдельных строк, BDD работает с буферами на данных». Это означает, что механизм потока данных инициирует буфер, заполняет его как можно большим количеством строк и перемещает этот буфер на следующий компонент (место назначения сценария в вашем случае). Как вы можете видеть, 5 буферов используются с одинаковым количеством строк. Если были запущены дополнительные буферы, вы бы видели больше путей. SSIS не мог использовать дополнительные буферы и, в конечном счете, дополнительные пути из-за механизма, называемого обратным давлением; это происходит, когда источник производит данные быстрее, чем получатель может его использовать. Если это произойдет, вся память будет использоваться исходными данными, а SSIS не будет использовать память для компонентов преобразования и назначения. Поэтому, чтобы избежать этого, SSIS ограничивает количество активных буферов. Он установлен на 5 (не может быть изменен), что соответствует количеству потоков, которые вы видите.

PS: Текст в кавычках из this article

Answer 2

В задачах потока данных SSIS есть свойство EngineThreads, которое определяет, сколько потоков может выполняться одновременно, а его значение по умолчанию равно 5 (в SSIS 2012 значение по умолчанию равно 10, поэтому я предполагаю, что вы используете SSIS 2008 или ранее.) Оптимальное значение зависит от вашей среды, поэтому, вероятно, потребуется некоторое тестирование, чтобы выяснить, что туда положить.

Вот Jamie Thomson article с более подробной информацией.

Answer 3

Еще одна интересная вещь, которую я обнаружил через this article on CodeProject.

[Т] его компонент использует внутренний буфер 9,947 строк (в соответствии с эксперимента я нашел так), и это заранее установленное. Невозможно переопределить . В качестве доказательства вместо 10 строк lac мы будем использовать только 9 947 (Nine тысяч девять сорок семь) строк в нашем исходном файле и будем наблюдать поведение . После запуска пакета мы обнаружим, что все строки переносятся на первый выходной компонент, а остальные компоненты ничего не получили.

Теперь давайте увеличим количество строк в нашем исходном файле с 9,947 до 9,948 (Девять тысяч девять сорок восемь). После запуска пакета мы получаем , что первый выходной компонент получил 9 947 строк, а второй выходной компонент получил 1 строку.

Таким образом, я заметил в вашем первом запуске буфера, что вы вытащили 50 000 записей. Они были разделены на 9 984 регистрационных ведра и переданы на каждый выпуск. Таким образом, BDD по существу берет записи, которые он получает из буфера, и передает их с шагом в 10 000 записей на каждый вывод. Поэтому в этом случае, возможно, ваш источник является узким местом.

Возможно, вам понадобится разделить исходный исходный запрос пополам и создать два потока данных, управляемых BDD, по существу, вдвое увеличить вашу параллельную пропускную способность.