Возникли проблемы с производительностью DB2OLEDB, при использовании sql server 2017 для выполнения загрузки данных из IBM i 7.3.
Клиент - VMware VM, сетевые настройки кажутся нормальными и настроены в меру моих возможностей.способность (vmxnet3 драйвер 1.8).Загрузка с других виртуальных машин или с www летает со скоростью более 100 Мбит.
Пока устранение неполадок: DB2OLEDB (Microsoft) работает значительно быстрее (в 3-5 раз), чем IBMDASQL.Установка маски ввода / вывода на одно ядро удваивает производительность, но дополнительные ядра не влияют.RSS включен.Включение / выключение незавершенного процесса DB2OLEDB не влияет на пропускную способность, но выключение обеспечивает значительное время спулинга в начале каждого запроса.
Производительность в настоящее время составляет около 15 Мбит.Та же таблица с другого сервера SQL (кэшированная) загружается примерно в 3 раза быстрее при 50 Мбит + (очевидно, другой поставщик).
Интересно, что включение rowcache повышает пропускную способность сети в начале до 100-150 Мбит.Т.е. я делаю вывод, что имеется достаточно пропускной способности сети.
Наконец, мы используем таблицу в памяти в качестве места назначения, чтобы исключить дисковый ввод-вывод в качестве виновника.
Процессоргорит одно ядро, а остальные находятся на уровне ~ 20%.
Есть мысли?
Я подозреваю, что драйвер DB2OLEDB или некоторая часть COM является узким местом на этом этапе.
edit: @MandyShaw (слишком долго для комментария) Windows Side.IBM i никогда не ломает 1% для моей конкретной рабочей нагрузки, и обычно он работает на 25% -50% в зависимости от TOD.Операторы SQL разнообразны.Все, от простого запроса из четырех частей до 7-ми столовой снежинки в виде прохода.Одна интересная вещь: пропускная способность (сеть) зависит от длины строки.Более широкие таблицы работают примерно с той же скоростью, что и более тонкие таблицы.Это верно как для драйвера IBM, так и для Microsoft.Снижение задержки в сети сильно повлияло на производительность (см. Проблемы RSC с драйвером Vmxnet3 1.6.6.0).Если я правильно понимаю, драйверы OLEDB извлекают по одной строке за раз (кроме, возможно, при загрузке кэша набора строк).
Другими словами, для каждой строки мы отправляем запрос от SQL-сервера к драйверу COM / OLEDB, к сетевому драйверу Supervisor, к сетевому драйверу гипервизора, к физическому NIC, через оптоволокно и посадку в IBM i.Тогда вернитесь снова.Мы успешно смогли мультиплексировать большие таблицы загрузки с помощью сервисного брокера (но это нецелесообразно для большинства приложений).Это, как и другие метрики, позволяет предположить, что IBM i обладает достаточным количеством процессоров и пропускной способности.Волокнистая структура в основном простаивает, мы настроили bejeezus из гипервизора (VMware) и супервизора (стек tcp / ip), а также самого сервера SQL.
Вот почему я ищу поставщика COM / OLEDB для ответов.Что-то в этой модели, кажется, воняет.Он либо неправильно настроен, либо просто не поддерживает несколько потоков выполнения.
Я также согласен с тем, что это что-то в SQL-сервере, но я не могу найти способсделать запрос связанного сервера многопоточным, используя любую комбинацию конфигурации, опций или подсказок.Опять же, это может быть просто невозможно по проекту.
На данный момент, немногие известные выводы, которые я имею, включают (1) настройку объединения и прерывания запросов сетевых прерываний для минимизации прерываний в потоке драйвера OLEDB и(2) использование шлюза HIS на потребительском компьютере x86 с высокой частотой одного ядра (5 ГГц) для максимизации однопоточной производительности.
Это оба дерьмовые варианты.
Если у вас есть что-то особенное в отношении производительности преобразования EBCIDIC / ASCII, я был бы рад попробовать и доложить.Стреляй мне по ссылке / инфо.