Nifi ExecuteSQLRecord: как выявить узкое место производительности - PullRequest
1 голос
/ 19 июня 2020

Цель

У меня есть Apache Nifi Docker контейнер на Azure ВМ с прикрепленным премиальным SSD-диском с очень высокой пропускной способностью. У меня есть база данных MS SQL Server 2012 на AWS. Связь Nifi с базой данных происходит через ms sql jar v6.2 и через сеть MPLS с высокой пропускной способностью AWS Direct Connect.

В Nifi Flow выполняется только один процессор - ExecuteSQLRecord. Он использует только один поток / процессор и имеет доступное пространство кучи JVM 4 ГБ. ExecuteSQLRecord выполнить запрос, возвращающий 1 миллион строк, что соответствует 60 МБ файла потока. Запрос основан на таблицах индексов, поэтому на стороне БД оптимизировать нечего. Запрос выглядит следующим образом: SELECT * FROM table WHERE id BETWEEN x AND y.

Проблема

ExecuteSQLRecord с 1 потоком / ЦП, 1 запросом, получает 1M строк (60 МБ) за 40 секунд. В то же время один и тот же запрос из MSSMS и внутренней сети базы данных занимает 18 секунд.

В то же время запрос уже оптимизирован на стороне БД (с индексами), а пропускная способность линейно увеличивается с увеличением количества потоков / ЦП - сеть не является узким местом.

Вопросы

  1. Подходит ли такая производительность для процессора Nifi 1? Это нормально, что Нифи тратит 22 секунды (из 40) на поиск и сохранение результатов в репозитории контента?
  2. Как Nifi извлекает данные с сервера MS SQL? Это вытягивающий подход? Если да, может быть, нам нужно много операций туда и обратно?
  3. Как я могу проверить, сколько времени Nifi тратит на преобразование набора результатов в CSV и сколько времени на запись в репозиторий контента?

Ответы [ 2 ]

2 голосов
/ 19 июня 2020

Вы используете последнюю версию Docker изображения (1.11.4)? Если это так, вы должны иметь возможность установить размер выборки на процессоре ExecuteSQLRecord (https://issues.apache.org/jira/browse/NIFI-6865)

Когда я искал размер выборки по умолчанию для MS, я получил несколько разных результатов. Драйвер SQL, один сайт сказал 1, а другой 32. В вашем случае для такого количества записей, я полагаю, вы захотите, чтобы он был намного выше (см. https://docs.microsoft.com/en-us/previous-versions/sql/legacy/aa342344 (v = sql 0,90 )? redirectedfrom = MSDN # use-the-Соответствующий-размер-выборки для установки соответствующего размера выборки).

1 голос
/ 19 июня 2020

Чтобы добавить к ответу Мэтта, вы можете изучить данные о происхождении для каждого потокового файла и увидеть продолжительность происхождения (количество времени), которое он провел в каждом сегменте потока. Вы также можете увидеть историю состояний для каждого процессора, так что вы можете проверить входящие / исходящие данные по размеру и количеству потоковых файлов, использованию ЦП и т. Д. c. для каждого процессора.

...