2016-11-23 6 views
1

У меня есть кластер ES 2.4.1 с 3 главными и 18 узлами данных, которые собирают данные журнала с созданием нового индекса каждый день. За один день размер индекса увеличивается примерно до 2 ТБ. Индексы старше 7 дней удаляются. В кластере выполняется очень мало поисковых запросов, поэтому основная цель - увеличить пропускную способность индексации.Elasticsearch: высокая загрузка процессора Lucene Merge Thread

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

EsRejectedExecutionException[rejected execution of [email protected] on EsThreadPoolExecutor[bulk, queue capacity = 50, [email protected]9ef44f[Running, pool size = 8, active threads = 8, queued tasks = 50, completed tasks = 68888704]]];]]; 

Узлы в кластере постоянно привязывая CPU. Я увеличил интервал обновления индекса до 30 с, но это мало повлияло. Когда я проверяю горячие потоки, я вижу несколько «Lucene Merge Thread» для каждого узла, используя 100% процессор. Я также заметил, что количество сегментов постоянно составляет около 1000 на каждый осколок, что, похоже, много. Ниже приведен пример стат сегмента:

"_2zo5": { 
    "generation": 139541, 
    "num_docs": 5206661, 
    "deleted_docs": 123023, 
    "size_in_bytes": 5423948035, 
    "memory_in_bytes": 7393758, 
    "committed": true, 
    "search": true, 
    "version": "5.5.2", 
    "compound": false 
} 

Чрезвычайно высокий «поколение» число беспокоит меня, и я хотел бы, чтобы оптимизировать создание сегментов и объединить, чтобы уменьшить нагрузку на ЦП на узлах.

Подробная информация о индексации и кластера конфигурации:

  • Каждый узел представляет собой экземпляр i2.2xl АМС с 8 процессорных ядер и 1.6T SSD-диски
  • Документы индексируются постоянно на 6 клиентских потоков с насыпной размером 1000
  • Каждый индекс имеет 30 осколков с 1 реплики
  • она занимает около 25 сек на партию из 1000 документов
  • /_cat/thread_pool? ч = насыпной * & v показывает тыс на bulk.completed равномерно разбросаны по узлам
  • Индекса размера буфера и долговечность транзакции останутся по умолчанию
  • _all отключен, но динамические отображения включены
  • Количество слияния потоков остаются по умолчанию, который должен ОК, учитывая, что я использую твердотельные накопители

Каков наилучший способ?

Спасибо!

+0

Как часто вы индексированию документов ? ESRejectedExecutionExceptions, которые выводят Значения, связанные с массовой массой, обычно означают, что вы перегружаете кластер массовыми запросами. – ryanlutgen

+0

Сколько у вас копий? Сколько осколков можно записать в любой момент времени? Каков ваш объемный размер? Знаете ли вы, насколько велика ваша средняя массовая просьба? Сколько времени занимает каждая вставка в миллисекундах? Когда вы смотрите/_cat/threadpool? H = bulk * & v, распространяются ли массовые запросы вокруг кластера или они избивают несколько выбранных узлов? Усилили ли вы размер буфера индекса? Вы смотрели на настройку долговечности для асинхронизации? Вы отключили _all? Разрешаете ли вы динамические сопоставления? – evanv

+0

Также вы используете ssds или шпиндели? Сколько слияний есть у вас? – evanv

ответ

1

Вот оптимизации, которые я сделал в кластер, чтобы увеличить пропускную способность индексации:

  • Увеличение threadpool.bulk.queue_size до 500, поскольку запросов индекса часто перегрузка очереди
  • Повышенных диск водяных знаков, поскольку настройки по умолчанию были слишком агрессивны для больших SSD, которые мы использовали. Я установил «cluster.routing.allocation.disk.watermark.low»: «100gb» и «cluster.routing.allocation.disk.watermark».высокий ":„10gb“
  • Удаляется неиспользуемые индексами, чтобы высвободить ресурсы ES использует для управления своими осколков
  • Увеличения числа первичных осколков до 175 с целью сохранения размера шарда под 50GB и имеет приблизительно осколок на процессор
  • Установить индекс клиента размера партии 10Мбы, который, казалось, работает очень хорошо для нас, потому что размер документов индексного изменяется резко (от KBS в мегабайты)

Надеется, что это помогает другим

0

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

Смежные вопросы