vert.x eventloop медленно потребляет от eventbus

Мы опрашиваем сообщения от kafka (используя Executor Thread) и помещаем их в шину событий vert.x. в конечном итоге вертикалы (неработающие) потребляют эти сообщения из шины событий.

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

по какой-то причине иногда шине событий требуется много времени, чтобы потреблять сообщения, но не отображать ошибку блока потока, поэтому мы не можем сказать, что задерживает его

странно, что мы не видим никаких предупреждений о блоках цикла событий. Что еще мы можем сделать? cpu / ram все в порядке. Единственная метрика, которая действительно может что-то показать, - это:

введите здесь описание изображения

но он нам ничего не говорит (понятия не имею, как обработчики шины событий могут быть связаны с задержкой цикла событий)

что мы должны проверить, чтобы понять, почему наше потребление цикла событий из шины событий vert.x должно быть медленным?


person rayman    schedule 21.12.2018    source источник
comment
Тебя трудно вести. Например, мы даже не знаем, откуда взялась эта метрика. Я бы посоветовал отправить сообщение на форум пользователей Vert.x с более подробным описанием вашего приложения.   -  person tsegismont    schedule 21.12.2018
comment
@tsegismont независимо от этого показателя. У вас когда-нибудь была ситуация, когда вы медленно потребляли из eventbus?   -  person rayman    schedule 21.12.2018
comment
Это локальная или распределенная шина событий?   -  person Alexey Soshin    schedule 23.12.2018
comment
@AlexeySoshin распределенная шина событий   -  person rayman    schedule 23.12.2018
comment
На основе Hazelcast?   -  person Alexey Soshin    schedule 23.12.2018
comment
@AlexeySoshin zookeeper. какие-нибудь идеи по этому поводу?   -  person rayman    schedule 23.12.2018
comment
любая идея, почему петля событий медленно потребляет из eventbus?   -  person rayman    schedule 24.12.2018


Ответы (1)


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

Возможно, вам стоит взглянуть на метрики jmx, предоставляемые проектом vertx-dropwizard-metrics < / а>. Это может быть полезно для вычисления временных рамок.

Вам также может быть интересно взглянуть на Java APM, например, glowroot, чтобы лучше понять, что не так. .

person Idriss Neumann    schedule 29.12.2018
comment
мы все это измеряем с помощью dropwizard. мы измеряем время, в течение которого сообщение было обработано, а также измеряли среднюю задержку каждого запроса цикла событий. мы не можем найти ничего экстремального. - person rayman; 30.12.2018
comment
@rayman Может быть, вам также следует проанализировать объем данных в памяти в те периоды, когда сообщения потреблялись слишком долго. Вам также следует взглянуть на Java APM, например на glowroot, чтобы лучше понять, что не так. - person Idriss Neumann; 31.12.2018
comment
как здесь поможет java APM? о чем мне следует заботиться? как это могло быть связано с медленным потреблением петли событий? - person rayman; 01.01.2019
comment
@rayman медленная петля событий может быть связана со многими причинами: количеством ожидающих потоков, размером пула потоков, объемом данных в памяти и т. д. java APM - это способ (среди прочего) анализировать такие вещи и находить, что не так. легче. - person Idriss Neumann; 01.01.2019