Вводная:
Elastic версии 6.4.2
4 дата-ноды, две hot и две warm + одна мастер нода
Общий объем данных 22Тб, индексов 199, шардов 1038, документов 20млрд
На hot нодах занято около 600Гб, остальное лежит на warm.
Есть ряд индексов crypto-money-metrics-btc-* (и аналогичный index pattern в кибане) которые хранятся на теплых нодах. Каждый индекс имеет две праймари шарды и одну реплику. Вот параметры индексов:
Есть другой ряд индексов weblog-* (и аналогичный index pattern в кибане) которые хранятся на теплых нодах, за исключением одного самого последнего, он храниться на горячих нодах т.к. в него идет активная индексация. Каждый индекс имеет 8 праймари шард и одну реплику. Вот параметры индексов:
Теперь описываю в чем проблема:
Идем в DIscover, открываем индекс патерн crypto-money-metrics-btc-*, выбираем любой день (не говоря уже о захватывании большего промежутка времени) и дальше возможно несколько вариантов:
ждем и кластер падает
ждем и получаем ошибку таймаута от кибаны, который у меня раскручен elasticsearch.requestTimeout: 99999
Пробуем еще раз и на второй-третей попытки кластер падает.
Вот что в это время происходит с одной из теплых нод (на второй картина примерно такая же):
Проблема наблюдается именно при работе с crypto-money-metrics-btc-.
Выше я не зря описал индексы weblog-, их так же много как и crypto-money-metrics-btc-*, они так же имеют большой объем. Но при этом при обращении к ним кластер не падает. Можно без проблем посмотреть любой день, неделю, можно даже захватить целый месяц. Да иногда при захвате большого по времени куска данных происходит ошибка таймаута от кибаны, но сделав еще попытку, данные в итоге отображаются и кластер при этом никогда не падает.
Помогите найти и понять проблему просмотра данных из crypto-money-metrics-btc-*, как ее решить?
Размер индекса ещё ни о чём не говорит - куда более интересны какие именно данные там (уровень вложенности и т.п) и самое главное - какие запросы для них запускаются.
Вполне может быть, что срабатывает circuit breaker, когда предчувствует, что может случится OOM. В этом случае надо смотреть на запрос, быть может, что ограничив размер корзины поможет
ЧТо касается запроса, то я же выше описал, речь идет про вкладку discovery в кибане, никаких дополнительных фильтров. Манипулирую только вкладкой Time Range в верхнем правом углу.
Вот для примера https://yadi.sk/i/1rkDRNjkH9u8JQ один из документов одного из индексов crypto-money-metrics-btc-* Вложений там действительно много, документ не простой.
Что касается документов в индексе weblog-*, то тут действительно сравнение видимо некорректное потому как документы там простые, а уж вложений нет и подавно.
Помогите мне, как все же оптимизировать crypto-money-metrics-btc-* или какие параметры кластера протюнинговать чтобы нормально работать в кибане с этими индексами.
Мэппинг дефолтный.
Стека нет. Потому как сколько не жди - нода полностью не умрет. Т.е. процесс эластика будет висеть, пытаться делать вид что он работает, а по факту эту ноду кластер видеть не будет. А в логах ноды будут сообщения от JvmGcMonitorService про overhead gc
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
