Настройка кластера под высокую нагрузку

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

Здравствуйте! Последнее время на моем кластере возникает ряд проблем с отвалами нод и индексов. Кластер состоит из 4 нод, все на SSD, под кучу выделено по 32Гб из 64.

По данным мониторинга я понимаю, что это происходит из-за длительной сборки мусора которая происходит по 2-3, а то и 5 минут. Следуя документации мне нужно увеличить параметр ping_retries до 10, что бы ноды висящие по 5 минут не отваливались (10 попыток по 30 секунд).

Подскажите, пожалуйста, правильно ли я думаю и каким потенциальным проблемам может привести столь длительное ожидание отклика ноды?

Возможно мне стоит масштабировать свой кластер, не могли бы Вы взглянуть своим профессиональным взглядом на данные моего мониторинга? По этой ссылке pdf с состоянием одной ноды и индекса в момент отвала, а так же общую картину за 2 и 7 дней.

2

Здравствуйте!
Какая версия Эластика? Можете залить логи с нод?
По графикам не видно чтобы сборка мусора длилась минутами

3

Данис, у нас стоит версия 6.4.3. Логи загрузил сюда.

Я решил, что это из-за сборки мусора потому что перед тем как нода перестает отвечать происходит резкий скачек использования кучи. Так же периодически у меня возникает переполнение очереди на bulk вставку.

4

У вас 3 issue:

  1. Caused by: org.elasticsearch.common.io.stream.NotSerializableExceptionWrapper: too_many_clauses: maxClauseCount is set to 1024
  2. Caused by: org.elasticsearch.common.util.concurrent.EsRejectedExecutionException: rejected execution of org.elasticsearch.ingest.PipelineExecutionService$1@98ed61c on EsThreadPoolExecutor[name = WIN-2/write, queue capacity = 200, org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor@2d8cfc9[Running, pool size = 8, active threads = 8, queued tasks = 1469, completed tasks = 145589831]]
  3. [2019-09-09T01:01:17,136][WARN ][o.e.g.DanglingIndicesState] [WIN-0] [[tenders_commerce_index_2015/cezLHePkRv2HwFA5BPhRDA]] can not be imported as a dangling index, as an index with the same name and UUID exist in the index tombstones. This situation is likely caused by copying over the data directory for an index that was previously deleted.
    Вы вероятно вручную скопировали папки с индексами где уже существовали индексы с такими именами. Эластик не может их импортировать ()

1 и 2 лечится тюнингом. 3 - просто аккуратно удалить папки указанные в логе

Думаю, что причина "выпадения" ноды в п.2

5

Под тюнингом вы понимаете изменять значения по умолчанию или добавлять ноды?

6

п.2 - поменять дефолтные значения, например:

thread_pool.write.size: 24
thread_pool.write.queue_size: 5000

п.1 - для начала я бы попытался оптимизировать запрос и уже потом бы поменял значение

7

Мне не особо понятен такой момент, если мы предполагаем, что нода отваливается под нагрузкой от индексации, то увеличение количества потоков вставки и увеличение размера очереди вызовет еще большую нагрузку на память, что будет приводить к более частым отвалам. Или я ошибаюсь?

8

Память вообще не причём. С Heap size и сборщиком мусора всё нормально.
Не сама индексация виновата, а переполнение очереди

9

Ясно, спасибо за помощь. Попробую увеличить эти параметры.

10

  1. Я бы начал с чистки dangling indices. Это не критично, но это засоряет логи и добаваляет не нужную нагрузку на узлы. Процесс можно посмотреть тут

  2. GC и правда большие, но судя по графикам, память достаточно. У вас эти сервера - железо или виртуалки? У вас там ничего не свапиться?

  3. Что с сетью, там никакие "умные" раутеры не стоят? Что-то сетевой трафик очень не стабильный, хотя причина может быть в GC

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

11

Спасибо! Действительно, вижу что java читает из файла подкачки, скорей всего это корень всех проблем с подвисаниями.

12

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