7.3.2 и потеря мастера

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

GET _nodes

GET _nodes/stats

Да, у нас на каждой ноде 128 Гб RAM, и под Heap отдано 96 Гб.
Но после миграции по версиям с 6.0 и до 7.4 потребление памяти уменьшилось
Сейчас можно и уменьшить раза в 2
Но меньше 30 боюсь не удастся - не запустится, настолько много шард

42

Да, lucene использует по 12-13 Гб на свои нужды, fielddata - маленький, надо уменьшать осторожно. Но уменьшать надо и если будет не хватать - то надо добавлять узлы.

43

А запускать на одной ноде несколько сервисов Эластика насколько я понял уже не рекомендуется?

До скольки для начала можно уменьшить?
Рекомендуете убрать мастер роль со всех дата нод?

44

Это все-равно лучше, чем запускать узлы с 60Гб памяти.

Затрудняюсь тут что-то сказать. У меня опыта работы с узлами с такими большими хипами - нет.

В принципе - да, но у вас не так много узлов в данный момент. Если вы со всех узлов данных эту роль уберете, то кто будет управлять кластером?

45

У нас есть несколько виртуалок. Думаю 3 ноды можно поднять для управления

Насколько я понял сейчас все тормоза из-за большего времени сборки мусора?

46

На всякий случай наш конфиг:

http.max_content_length: 256mb
node.master: true
node.data: true
index.codec: best_compression

thread_pool.write.queue_size: 5000
indices.memory.index_buffer_size: 20%

47

Решили попробовать поднять на каждом физическом сервере по 3 ноды, т.е. будет 7 * 3 = 21 нода
Каждой ноде дать 29 Гб RAM, т.е. 40 останется на файловый кэш
Как в таком случае разбивать индекксы на шарды: на каждый индекс 21 шарду?

48

Логи с мастера и ещё одной ноді за сегодня:


Утром ещё убрали четверть нагрузки с кластера. Таймауты получения статистики всё равно остались.
Самое интересное, что до этого с большей нагрузкой на 6.8, 7.3 такого никогда не было

49 
http.max_content_length: 256mb

Это у Вас такие большие сообщения?

thread_pool.write.queue_size: 5000

А это зачем?

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

50

Мы пишем батчами. Бывают больше сотни Мб. После оптимизации не знаю доходит ли до 200 Мб

Много активных индексов в которые пишется и очереди в 200 не хватало, были реджекты

51

Батчи можно было бы и уменьшить.

Реджекты надо обрабатывать на клиенте, или добавить очередь какую-нибудь, а не сваливать эту работу на elasticsearch.

52

Сейчас сделали ElasticSearchWriterPool который регулирует максимальную параллельность записи и динамически регулирует батчи

53

У нас похожий сценарий и бывает клиенты загружают очень много данных, правда никогда не переваливали дефолтные значения. Опытным путем выбраны настройки для параллельности и батчи для bulks + circuit breaker/retry логика, чтобы не перегружать кластер. Я хотел спросить, интересно, как устроен ElasticSearchWriterPool, т.е. от чего он отталкивается и как он работает чтобы определить эти параметры?

Раньше тоже были проблемы с queue_size, но теперь таких проблем нет. Остались только проблемы с переездом на 7.4.0 (пока никто не помог). При downgrade на 7.3.2 - все хорошо.

54

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

Вот лог с координатора

Почему нода так долго не могла присоединиться к кластеру?

Есть ещё логи похожие. Чуть позже приложу. В логах GC даже нет

Лог с node-00, которая была выбрана в это время мастером и отключила node-master считая, что начался лаг

55

node-00 утверждает, что node-master целых 3 минуты делала publication of cluster state version
Но там мало шард, cluster state передаётся как диффы. Это очень странно

56

Проблема, может быть в elasticsearch, или в том, как ваша сеть или виртуалки работают. Если бы проблема была в elasticsearch, то мы бы видели что-то в github.

Чтобы разобраться, что там конкретно не работает, было бы хорошо посмотреть на логи на более низком уровне: logger.org.elasticsearch.cluster.service:TRACE и logger.org.elasticsearch.gateway.MetaStateService:TRACE.

Кстати, время в логах отличается на несколько часов. Это так машины настроены, или это логи выбраны в разное время?

57

TRACE добавляю.
На дата нодах выставлен UTC, а на координаторе текущий пояс. Тоже исправляю.
Жду следующего такого случаю и пришлю логи
Спасибо

58

По поводу ошибки обновления cluster:monitor/nodes/stats которая возникает на продакшене
Словили её и на тесте. В это время ни на node-master ни на node-00 не было нагрузки на процессор или диск и с сетью всё было хорошо.
Кстати, node-master периодически вылетает из кластера, но за сотые доли секунды переподключается. Якобы это TransportException и разрывается tcp коннекшен. С этим ещё разбираемся.

Лог с node-00:

Лог с node-master:

59

Может, у вас там какое-нибудь "умное" сетевое оборудование умничает и обрывает соединения? Как у вас сеть настроена? Еще не очень понятно, почему логи обрезаны. Например:

[2019-10-25T15:36:08,734][DEBUG][o.e.c.s.ClusterApplierService] [node-master] processing [ApplyCommitRequest{term=79, version=22649, sourceNode={node-00}{cMIMAQ2cQBKx-0W0VqGzrg}{X9k02oS0SRKNhqdtvPeI8g}{192.168.11.3

Строка заканчивается на самом интересном месте. Пока что, дело ясное, что дело темное. Было бы полезно еще org.elasticsearch.cluster.coordination: TRACE добавить к следующему сбою и логи не резать.

60

Да, извиняюсь, вырезал всю мета-информацию об индексах и зацепил

В той строчке:
[2019-10-25T15:36:08,734][DEBUG][o.e.c.s.ClusterApplierService] [node-master] processing [ApplyCommitRequest{term=79, version=22649, sourceNode={node-00}{cMIMAQ2cQBKx-0W0VqGzrg}{X9k02oS0SRKNhqdtvPeI8g}{192.168.11.39}{192.168.11.39:9300}{dim}}]: took [0s] done applying updated cluster state (version: 22649, uuid: glYQaVfWRFKOEKrkg02zng)

Добавил в конфиг logger.org.elasticsearch.cluster.coordination: TRACE, жду логов)

Спасибо