Кортежи, занимающие больше времени при переходе от носика к последнему болту (он же полная задержка), высоки - PullRequest
Новая
       7

Кортежи, занимающие больше времени при переходе от носика к последнему болту (он же полная задержка), высоки

0 голосов
/ 27 октября 2018 
Version Info: 
   "org.apache.storm" % "storm-core" % "1.2.1" 
   "org.apache.storm" % "storm-kafka-client" % "1.2.1"

Я создавал и экспериментировал с созданной мною топологией Storm, которая имеет 4 болта и один носик кафки.

Я пытался настроить конфиги, такие как параллельность этих болтов, ожидание max-spoutи т. д., чтобы увидеть, насколько масштаб я могу получить из этого.После некоторых настроек конфигурация / результаты будут выглядеть примерно так: 

max-spout-pending: 1200
Kafka Spout Executors: 10
Num Workers: 10
+----------+-------------+----------+----------------------+
| boltName | Parallelism | Capacity | Execute latency (ms) |
+----------+-------------+----------+----------------------+
| __acker  |          10 | 0.008    | 0.005                |
| bolt1    |          15 | 0.047    | 0.211                |
| bolt2    |         150 | 0.846    | 33.151               |
| bolt3    |        1500 | 0.765    | 289.679              |
| bolt4    |          48 | 0.768    | 10.451               |
+----------+-------------+----------+----------------------+

Задержка процесса и задержка выполнения практически одинаковы.Для болта 3 используется HTTP-вызов, который занимает примерно столько же времени, а болт 2 и болт 4 также выполняют некоторые операции ввода-вывода.

Хотя я вижу, что каждый болт может обрабатывать более 3 тыс. По отдельности, (bolt3: 1500 / 289.679ms = 5,17 кбит / с, bolt 4: 48 / 10,451ms = 4,59 кбит / с и т. д.), но в целом эта топология обрабатывает кортежи со скоростью всего ~ 3 кбит / с.Я использую его на 10 коробках (по одному рабочему на коробку), имея 12-ядерный процессор и 32 ГБ ОЗУ.Я дал каждому рабочему процессу -xms 8Gb и -xmx 10Gb, поэтому ОЗУ также не должно быть ограничением.Я вижу, что GC также работает правильно, 4 GC в минуту, занимающие общее время 350 мс в минуту (из записи полета рабочего процесса за 1 минуту).

Я вижу Complete Latency для каждого кортежа около 4sec, чего я не могу понять, так как если я вычисляю все время, затраченное на все болты, это составляет около 334 мс, но, как уже упоминалось здесь , кортежи могут ожидать в буферах, он предлагаетувеличьте dop (степень параллелизма), что я сделал и достиг состояния выше.

Я добавляю еще несколько измерений и вижу, что кортежам требуется в среднем около 1,3 секунды, чтобы достичь от болта 2 до болта 3 и 5 сек.от болта 3 до болта 4. Хотя я понимаю, что Storm может хранить их в исходящем или входящем буфере, мой вопрос заключается в том, как уменьшить его, так как эти болты должны обрабатывать больше кортежей в секунду, в соответствии с моими предыдущими вычислениями, чтоудерживает их от входа и обрабатывается с большей скоростью?

1 Ответ

0 голосов
/ 07 ноября 2018

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

У вас много болтов и предположительно высокая пропускная способность, что приведет к большому количеству ack сообщений. Попробуйте увеличить количество атакующих, используя конфигурационное значение topology.acker.executors, которое, мы надеемся, уменьшит задержку в очереди для кортежей ack.

Если вы также используете пользовательский пользовательский показатель, вы также можете увеличить параллельность этого компонента, учитывая количество имеющихся у вас болтов.

...