Неожиданный java.io.IOException: failed to obtain in-memory shard lock


(Михаил) #1

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


(Vladimir Dolzhenko) #2

Первое, что приходит в голову - из-за большой нагрузки на ноду случилась более длинная, чем timeout GC пауза. Посмотрите в gc log-и и возможно стоит увеличить timeout-ы.


(Михаил) #3

А можно подробнее, где этот gc log и о каких таймаутах идет речь и где их крутить?


(Vladimir Dolzhenko) #4

gc логи: logs/gc.log*

ping timeout: https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-discovery-zen.html


(Михаил) #5

У меня конфиг такой
https://pastebin.com/90nf27sk
Судя по всему он тянется еще со старых версий эластика. GC логов нет.

Рядом еще лежит вот такой, видимо прилетел с последним rpm эластика:
https://pastebin.com/ymALL3nm

Java у меня от oracle , восьмой версии. Перейти на новый jvm конфиг чтобы началась сборка gc логов и наблюдать дальше за ситуацией?
Можно ли как-то разобрать текущую ситуацию без gc логов?

Вы говорите о том что кластер был перегружен, но по мониторингу никакой излишней нагрузки до падения (напомню оно было примерно в 16:30) не наблюдается, вот скрин ноды на которой отлетел шард:


(Vladimir Dolzhenko) #6

Боюсь, что без gc логов это будет гаданием на кофейной гуще

во втором конфиге написано

8:-Xloggc:/var/log/elasticsearch/gc.log

ищите логи там

что касается нагрузки: по графикам видно, что размер heap-а уменьшается с ~23Gb до ~6-7Gb каждые полчаса - это вполне укладывается в работу GC, которая могла вызывать неотзывчивость jvm.


(Михаил) #7

@Igor_Motov Игорь, я извиняюсь, но очень хочется узнать Ваше мнение по моему вопросу.


(Igor Motov) #8

Я обычно читаю все сообщения в форуме. Молчу, потому что добавить мне, в общем-то, нечего. Судя по всему нода данных потеряла связь с мастером или наоборот, обычно это бывает из-за GC как @Vladimir.Dolzhenko уже и сказал. Другие возможные проблемы - сеть, перегрузка машины, перегрузка VM, и т.д. Долгая сборка мусора - наиболее частый симптом.


(Михаил) #9

Снова произошел сбой с потерей связи одной из нод с мастером 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 минут после:

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


(Михаил) #10

Ситуация периодически напоминает о себе. Нужна помощь, как быть?


(Igor Motov) #11

Вы не могли бы прислать полный лог с ноды, которая упала и с мастера в день, когда произошел сбой?


(Михаил) #12

Игорь, к сожалению не могу вывалить логи в общий доступ.
Выслал вам архив с логами на почту.


(Igor Motov) #13

Странно, судя по логам перед падением все очереди на ноде переполняются. У вас все это на физическом железе или VM? Диски какие?


(Михаил) #14

конкретно srv04 это физический сервер, имеет 6 дисков с вот такими характеристиками:

Interface Type: SAS
Size: 600 GB
Rotational Speed: 15000

диски собраны в raid 1+0


(Igor Motov) #15

Пока из всего, что я видел, картина такая - перед выпадом ноды у нее все запросы на поиск и индексирование застревают. Интересно было бы подловить этот момент и посмотреть где они застряли. То есть если запустить jstack непосредственно перед моментом перегрузки, то это дало бы нам некоторую информацию, о том, что происходит.

А в среднем, сколько записей у вас в очередях поискового thread pool?


(Михаил) #16

Проверял вот так:

GET /_cat/thread_pool/search?v&s=node_name:desc

Очередь почти всегда нулевая, иногда (редко) бывает показывает не ноль, но меньше 10 всегда.
Ну а как отловить момент когда выросла очередь но еще не отвалились шарды чтобы снять этот jstack, кейс выглядит нереально?
Посмотреть jstack сразу как отвалились шарды не поможет?


(Igor Motov) #17

Посмотреть jstack сразу как отвалились шарды не поможет?

Если сразу - то может помочь.


(system) #18

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