Производительность db2oledb в сравнении с многопоточностью
Возникла проблема с производительностью DB2OLEDB, при использовании sql server 2017 выполняется загрузка данных из IBM i 7.3 .
Клиент - VMware VM, сетевые настройки кажутся нормальными и были настроены в меру моих возможностей (vmxnet3 driver 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, я был бы рад попробовать и доложить. Стреляй мне ссылку / инфо.