Добрый день!
В последние 2 дня наблюдаем на одной ноде нагрузку в 1.5-2 раза больше чем на других по i/o
В hot threads постоянно вижу там:
41.8% (208.8ms out of 500ms) cpu usage by thread 'elasticsearch[node-00][[session_201907_2][4]: Lucene Merge Thread #7552]'
Т.е. мёржатся сегменты на индексе в который запись уже не идёт. Причём это начинается каждый день в 12 часов.
Можно ли этого как-то избежать?
На всех индексах и шаблонах для новых включил index.merge.scheduler.max_thread_count = 1, т.к. у нас рейды из обычных дисков
Спасибо
Elasticsearch 6.8.1. Планируем обновиться до 7.х
А 12 часов - это в какой часовой зоне? Просто в elasticsearch такие вещи сами по себе не происходят. Это, скорее всего, либо ILM, либо какой-то внешний процесс типа curator или что-то в этом роде.
В 12 по UTC. ILM, curator не используем, только чистый Elasticsearch. Установив index.merge.scheduler.max_thread_count = 1 удалось немного уменьшить нагрузку на ту ноду. Но разрыв по нагрузке в 2 раза вечером остаётся. Трафик льётся по шардам абсолютно равномерно per node - тут перекоса нет нигде.
Насколько я понял можно попробовать уменьшить disk i/o увеличив index.translog.flush_threshold_size
Проверил всё что можно, но на одной ноде(node00) большой перекос по нагрузке. Она, кстати, выбрана в ходе выборов как master.
hot_threads на ноде высоконагруженной: https://gist.github.com/UkrZilla/8ef45948b351456c054cb9bbe2b90241
hot_threads на ноде с нормальной нагрузкой: https://gist.github.com/UkrZilla/0821bc19f4e1adf298e3d719d8de6727
Может быть, просто так получилось, что на node00 попали шарды, в которые вы особенно интенсивно индексируете? Я там ничего, кроме
У нас 7 нод
У всех индексов: "number_of_shards": "7", "number_of_replicas": "1"
Я думал, что в таком случае т.к. у каждой ноды есть своя primary шарда индекса, то и нагрузка по индексации будет равномерной
На месяц мы отключали ребаланс шард:
"cluster.routing.rebalance.enable" : none
Вчера вернули, но ничего не поменялось
Это не факт. Посмотрите, как на самом деле шарды распеределены cat shards API | Elasticsearch Guide [8.11] | Elastic
Приблизительно одинаково, сгруппировал ноды по primary shard count:
node-00 1421
node-01 1530
node-02 1295
node-03 1224
node-04 1543
node-05 1145
node-06 1152
Насколько я понял можно попробовать увеличить коэффициент cluster.routing.allocation.balance.shard чтобы включить выравнивание
Я думаю, что не в количестве дело, а в качестве. У вас ведь на во все 1421 шарды на node-00 каждый день все индексируется. Важно количество активных на данный момент шард и их принадлежность к индесксам.
Если очень надо что-то покрутить, то я бы стал куртить cluster.routing.allocation.balance.index. Но лучше, все-таки сначала разобраться в чем проблема.
В том-то и дело, что в 99% индексов идёт запись в реальном времени через bulk insert, конечно
Раньше, до отключения ребаланса шард, кластер активно, я бы сказал агрессивно, делал ребаланс гоняя данные на гигабитных скоростях
Проанализировав нагрузку выяснили, что 90% нагрузки идёт от одного лога. Отключив его индексацию перекос уменьшился значительно. Настолько, что его почти не видно, т.к. тот лог очень большой, с большим мэппингом и события очень часто происходят.
Шарды индекса этого лога распределены равномерно по нодам, поэтому непонятно почему нагрузка индексации ложится только на одну ноду
Раутинг или parent/child отношения используются?
Ничего такого не используем. Сейчас перезагрузили эту ноду. Выбрался новый master, поднимутся все шарды и посмотрим
С нетерпением ждём 7.3 (https://github.com/elastic/elasticsearch/pull/43616)
Есть новости: обычно после перезагрузки ноды на ней мало primary shard, но постепенно она их набирала за сутки, двое до приблизительно одинакового количества как на других нодах и кластер опять становился сбалансирован. Но сейчас, после перезагрузки, на ней только 4 primary, остальные реплики, и ничего не меняется.
Есть предположение, которое и раньше выдвигал, что подействовало отключение ребаланса шард. Впрочем позже мы его включили обратно, но вероятно кластер заполнил. Ведь всего одна нода была перезагружена. Но это единственное что из настроек мы трогали и только предположение.
Нагрузка на праймари и репликах должна быть идентична, если только вы не выполняете какие-нибудь тяжелые операции update.
Никаких update не делаем. Всё излечилось полным перезапуском кластера и обновлением до 6.8.2
Воспроизвели опять баг и выяснили, что такое происходит при удалении группы закрытых индексов. Индексы удаляются, а что потом происходит в кластере - неясно. Но снижение производительности индексации, перекос нагрузки по нодам на лицо
А индексы были закрыты до обновления или после? С какой версии обновлялись?