Elastic версии 6.4.2
4 дата-ноды, две hot и две warm + одна мастер нода
Общий объем данных 22Тб, индексов 199, шардов 1038, документов 20млрд
На hot нодах занято около 600Гб, остальное лежит на warm.
Вчера днем происходит неожиданный unnsigned шард для индекса netflow-2018.10.22 (лежит на hot нодах, два праймари шарда и две реплики) индекс самый активный из всех по части индексации (около 3000 праймари событий в секунду). В логи заглянуть времени не было, принудительный reroute не помог. Отключил реплику для индекса, а затем включил снова, реплики создались и кластер позеленел.
Далее в 16:30 ситуация повторилась с тем же индексом с тем же шардом. reroute снова не помог, полез в логи, пока изучал прошло какое-то время и при очередной попытке сработал reroute, шард распределился и кластер позеленел.
Помогите понять чем вызвана такая проблема и как с ней бороться?
Вот ссылка на логи https://pastebin.com/sX9UsR0Y
Первое, что приходит в голову - из-за большой нагрузки на ноду случилась более длинная, чем timeout GC пауза. Посмотрите в gc log-и и возможно стоит увеличить timeout-ы.
А можно подробнее, где этот gc log и о каких таймаутах идет речь и где их крутить?
gc логи: logs/gc.log*
ping timeout: https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-discovery-zen.html
У меня конфиг такой
https://pastebin.com/90nf27sk
Судя по всему он тянется еще со старых версий эластика. GC логов нет.
Рядом еще лежит вот такой, видимо прилетел с последним rpm эластика:
https://pastebin.com/ymALL3nm
Java у меня от oracle , восьмой версии. Перейти на новый jvm конфиг чтобы началась сборка gc логов и наблюдать дальше за ситуацией?
Можно ли как-то разобрать текущую ситуацию без gc логов?
Вы говорите о том что кластер был перегружен, но по мониторингу никакой излишней нагрузки до падения (напомню оно было примерно в 16:30) не наблюдается, вот скрин ноды на которой отлетел шард:
Боюсь, что без gc логов это будет гаданием на кофейной гуще
во втором конфиге написано
8:-Xloggc:/var/log/elasticsearch/gc.log
ищите логи там
что касается нагрузки: по графикам видно, что размер heap-а уменьшается с ~23Gb до ~6-7Gb каждые полчаса - это вполне укладывается в работу GC, которая могла вызывать неотзывчивость jvm.
Я обычно читаю все сообщения в форуме. Молчу, потому что добавить мне, в общем-то, нечего. Судя по всему нода данных потеряла связь с мастером или наоборот, обычно это бывает из-за GC как @Vladimir.Dolzhenko уже и сказал. Другие возможные проблемы - сеть, перегрузка машины, перегрузка VM, и т.д. Долгая сборка мусора - наиболее частый симптом.
Снова произошел сбой с потерей связи одной из нод с мастером java.io.IOException: Время ожидания соединения истекло, но в этот раз без java.io.IOException: failed to obtain in-memory shard lock, хотя часть шардов все равно стали Unassigned.
Потеря связи произошла в 2018-10-25T10:50:46,100
Вот gc.log https://pastebin.com/QNaYgsq9, я если честно ничего в нем полезного не нашел к моему сожалению.
ВОт скрин ноды за 10 минут до потери связи с мастером и 10 минут после:
Опять же перегрузок каких-либо аномальных не наблюдаю. Сеть проверил сейчас с людьми ответственными за нее, проблем так же не обнаружилось.
Ситуация периодически напоминает о себе. Нужна помощь, как быть?
Вы не могли бы прислать полный лог с ноды, которая упала и с мастера в день, когда произошел сбой?
Игорь, к сожалению не могу вывалить логи в общий доступ.
Выслал вам архив с логами на почту.
Странно, судя по логам перед падением все очереди на ноде переполняются. У вас все это на физическом железе или VM? Диски какие?
конкретно srv04 это физический сервер, имеет 6 дисков с вот такими характеристиками:
Interface Type: SAS
Size: 600 GB
Rotational Speed: 15000
диски собраны в raid 1+0
Пока из всего, что я видел, картина такая - перед выпадом ноды у нее все запросы на поиск и индексирование застревают. Интересно было бы подловить этот момент и посмотреть где они застряли. То есть если запустить jstack непосредственно перед моментом перегрузки, то это дало бы нам некоторую информацию, о том, что происходит.
А в среднем, сколько записей у вас в очередях поискового thread pool?
Проверял вот так:
GET /_cat/thread_pool/search?v&s=node_name:desc
Очередь почти всегда нулевая, иногда (редко) бывает показывает не ноль, но меньше 10 всегда.
Ну а как отловить момент когда выросла очередь но еще не отвалились шарды чтобы снять этот jstack, кейс выглядит нереально?
Посмотреть jstack сразу как отвалились шарды не поможет?
Посмотреть jstack сразу как отвалились шарды не поможет?
Если сразу - то может помочь.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.