Падает кластер при работе с определенными индексами

Elastic In Your Native Tongue Вопросы на русском языке
1

Вводная:
Elastic версии 6.4.2
4 дата-ноды, две hot и две warm + одна мастер нода
Общий объем данных 22Тб, индексов 199, шардов 1038, документов 20млрд
На hot нодах занято около 600Гб, остальное лежит на warm.

Есть ряд индексов crypto-money-metrics-btc-* (и аналогичный index pattern в кибане) которые хранятся на теплых нодах. Каждый индекс имеет две праймари шарды и одну реплику. Вот параметры индексов:

image
image.png1016×775 69.9 KB

Есть другой ряд индексов weblog-* (и аналогичный index pattern в кибане) которые хранятся на теплых нодах, за исключением одного самого последнего, он храниться на горячих нодах т.к. в него идет активная индексация. Каждый индекс имеет 8 праймари шард и одну реплику. Вот параметры индексов:

image
image.png922×666 52.3 KB

Теперь описываю в чем проблема:
Идем в DIscover, открываем индекс патерн crypto-money-metrics-btc-*, выбираем любой день (не говоря уже о захватывании большего промежутка времени) и дальше возможно несколько вариантов:

  1. ждем и кластер падает
  2. ждем и получаем ошибку таймаута от кибаны, который у меня раскручен elasticsearch.requestTimeout: 99999
    Пробуем еще раз и на второй-третей попытки кластер падает.

Вот что в это время происходит с одной из теплых нод (на второй картина примерно такая же):

image
image.png1785×653 133 KB

Проблема наблюдается именно при работе с crypto-money-metrics-btc-.
Выше я не зря описал индексы weblog-, их так же много как и crypto-money-metrics-btc-*, они так же имеют большой объем. Но при этом при обращении к ним кластер не падает. Можно без проблем посмотреть любой день, неделю, можно даже захватить целый месяц. Да иногда при захвате большого по времени куска данных происходит ошибка таймаута от кибаны, но сделав еще попытку, данные в итоге отображаются и кластер при этом никогда не падает.

Помогите найти и понять проблему просмотра данных из crypto-money-metrics-btc-*, как ее решить?

2

Размер индекса ещё ни о чём не говорит - куда более интересны какие именно данные там (уровень вложенности и т.п) и самое главное - какие запросы для них запускаются.

Вполне может быть, что срабатывает circuit breaker, когда предчувствует, что может случится OOM. В этом случае надо смотреть на запрос, быть может, что ограничив размер корзины поможет

https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-terms-aggregation.html#search-aggregations-bucket-terms-aggregation-size

и опять же - так сложно сказать - нужно смотреть и анализировать логи.

3

ЧТо касается запроса, то я же выше описал, речь идет про вкладку discovery в кибане, никаких дополнительных фильтров. Манипулирую только вкладкой Time Range в верхнем правом углу.

ВОт логи https://pastebin.com/4ZtJjL49

Вот для примера https://yadi.sk/i/1rkDRNjkH9u8JQ один из документов одного из индексов crypto-money-metrics-btc-* Вложений там действительно много, документ не простой.

Что касается документов в индексе weblog-*, то тут действительно сравнение видимо некорректное потому как документы там простые, а уж вложений нет и подавно.

Помогите мне, как все же оптимизировать crypto-money-metrics-btc-* или какие параметры кластера протюнинговать чтобы нормально работать в кибане с этими индексами.

4

А меппинг у crypto-money-metrics-btc-* какой? А когда нода с OOM падает стек есть?

5

Мэппинг дефолтный.
Стека нет. Потому как сколько не жди - нода полностью не умрет. Т.е. процесс эластика будет висеть, пытаться делать вид что он работает, а по факту эту ноду кластер видеть не будет. А в логах ноды будут сообщения от JvmGcMonitorService про overhead gc

6

А что stats показывают перед тем, как нода помирает?

7

Игорь, Вы об этом Nodes stats API | Elasticsearch Guide [8.11] | Elastic ?

воспроизведу ситуацию и сниму тогда

8

Да про это. Если там ничего не найдем, то следующим шагом будет анализ heapdump-а.

9

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.