How to improve io performance in elasticsearch

Всем привет.

пытаюсь улучшить скорость записи в elasticsearch по этому документу.
https://www.elastic.co/guide/en/elasticsearch/guide/current/indexing-performance.html

попутно возникла идея создать несколько машинок с быстрыми дисками и делать индексацию только на них.
а потом копировать эти индексы на другие ноды.

В связи с этим вопросы:
правильное ли это направление для решения подобной задачи?
есть ли решения лучше ?

Привет, а в чем проблема сейчас? Какая скорость загрузки сейчас, какая загрузка I/O и CPU (есть ли запас)?

Мы упирались в 20-25тыс. документов на 1 инстанс ES, но сервера позволяли ставить еще несколько инстансов и суммарно получали прирост скорости добавляя еще 1-2 инстанса на одном железном сервере, каждый обрабатывал уже чуть меньше, но не существенно, 18-23тыс. документов в секунду на каждый инстанс. Важный момент, надо делать настройку, чтобы реплики не создавались на одном сервере с primary, чтобы не портить отказоустойчивость.

Направление решения - хорошее, особенно если позволяют деньги и исчерпаны другие варианты. Это называется hot-cold architecture, насколько помню делается за счет роутинга.

Привет ,
у нас 20 data nodes. В день приходит 4Тб данных. В часы пик скорость записи 90k За настройку спасибо. Документ про hot-cold architecture изучил.
https://www.elastic.co/blog/hot-warm-architecture .

Интересно как реагирует кластер на такого рода копии.
Раз в день когда дата будет переходить с горячих нодов на тепленкие , не застынет ли он? Как можно рассчитать, как оптимально перегонять данные с hot-nodes to warm nodes?

Про скорость переноса из опыта не скажу, но, ИМХО, не хуже чем ребаланс шардов в пределах кластера.
Если кластер не дикое легаси из 0.х или 1.х, можно посмотреть в сторону 5-й версии, в ней обещали увеличить скорость индексации и общее улучшение работы.

Все же, в чем сейчас проблема?

Посмотрел ваш пост в ветку про logstash с тем же вопросом :wink: так вот, сам logstash может являться тормозом загрузки, он бывает очень нетороплив. И тут уже надо смотреть на состояние всего кластера, то что я спрашивал в первом ответе, а нагружен ли реально кластер? Если нет, если диски утилизированы меньше чем на 80%, никакой SSD не поможет, так как проблема на в дисках.

Привет,
Основная проблема в скорости переноса данных в кластер. Увеличение неторопливых logstash instances большого изменения не дает. ноды загружены частично. есть пара тройка с высоким CPU and IO остальные отдыхают. Сделал еще раз замеры на максимальной нагрузке . кластер пишет 40.000 документов в секунду. выше скорость записи не подымается. вот такая картина .

Если есть возможность, попробуйте загрузить кластер через кастомную утилиту типа rally или esBench, если кластер выдаст нормальную скорость (примерно 25к документов в секунду * на 20 дата-нод), тогда явно проблема с загрузкой из logstash. Если же другие утилиты не помогут, то проблема с самим кластером и его настройками.

Из очевидных "подводных камней":

  1. Нет ли дисбаланса шардов по тем нодам на которых наибольшая нагрузка? То есть грубо, не создал ли эластик большинство шардов, куда идет загрузка, на тех 2 нодах где всплеск нагрузки?
  2. Нет ли проблем со свободной памятью на ОС и насколько нагружен heap дата-нод и мастеров?
  3. Не уходят ли сервера в своп?
  4. Что делают эти несколько нагруженных нод, надо смотреть чем они заняты через hot-threads?
  5. Не меняли ли настройки эластика и JVM?

Огромное спасибо за помощь. Особенное за подводные камни и утилиты . Как ни странно проблема обнаружилась в Logstash , перемудрили маленько с фильтрами . После исправлений , летает как самолет :slight_smile:

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