Поиск thread_pool для определенных узлов всегда на максимуме

#java #elasticsearch #memory-leaks #garbage-collection

#java #elasticsearch #утечки памяти #сбор мусора

Вопрос:

У меня есть кластер elasticsearch с 6 узлами. Размер кучи устанавливается равным 50 ГБ.(Я знаю, что рекомендуется использовать менее 32, но по какой-то причине это значение уже было установлено на 50 ГБ, чего я не знаю). Теперь я вижу много отказов от поиска thread_pool.

Это мой текущий поиск thread_pool:

 node_name               name   active rejected  completed
1105-IDC.node          search      0 19295154 1741362188
1108-IDC.node          search      0  3362344 1660241184
1103-IDC.node          search     49 28763055 1695435484
1102-IDC.node          search      0  7715608 1734602881
1106-IDC.node          search      0 14484381 1840694326
1107-IDC.node          search     49 22470219 1641504395
  

Что-то, что я заметил, это то, что два узла всегда имеют максимальное количество активных потоков (1103-IDC.node и 1107-IDC.node ). Несмотря на то, что другие узлы также имеют отклонения, эти узлы имеют самые высокие значения. Аппаратное обеспечение аналогично другим узлам. Что может быть причиной этого? Может ли это быть связано с тем, что у них есть какие-то конкретные сегменты, где попаданий больше? Если да, то как их найти.?

Кроме того, молодая куча занимает более 70 мс (иногда около 200 мс) на узлах, где активный поток всегда максимален. Найдите ниже несколько строк из журнала GC:

 [2020-10-27T04:32:14.380 0000][53678][gc             ] GC(6768757) Pause Young (Allocation Failure) 27884M->26366M(51008M) 196.226ms
[2020-10-27T04:32:26.206 0000][53678][gc,start       ] GC(6768758) Pause Young (Allocation Failure)
[2020-10-27T04:32:26.313 0000][53678][gc             ] GC(6768758) Pause Young (Allocation Failure) 27897M->26444M(51008M) 107.850ms
[2020-10-27T04:32:35.466 0000][53678][gc,start       ] GC(6768759) Pause Young (Allocation Failure)
[2020-10-27T04:32:35.574 0000][53678][gc             ] GC(6768759) Pause Young (Allocation Failure) 27975M->26444M(51008M) 108.923ms
[2020-10-27T04:32:40.993 0000][53678][gc,start       ] GC(6768760) Pause Young (Allocation Failure)
[2020-10-27T04:32:41.077 0000][53678][gc             ] GC(6768760) Pause Young (Allocation Failure) 27975M->26427M(51008M) 84.411ms
[2020-10-27T04:32:45.132 0000][53678][gc,start       ] GC(6768761) Pause Young (Allocation Failure)
[2020-10-27T04:32:45.200 0000][53678][gc             ] GC(6768761) Pause Young (Allocation Failure) 27958M->26471M(51008M) 68.105ms
[2020-10-27T04:32:46.984 0000][53678][gc,start       ] GC(6768762) Pause Young (Allocation Failure)
[2020-10-27T04:32:47.046 0000][53678][gc             ] GC(6768762) Pause Young (Allocation Failure) 28001M->26497M(51008M) 62.678ms
[2020-10-27T04:32:56.641 0000][53678][gc,start       ] GC(6768763) Pause Young (Allocation Failure)
[2020-10-27T04:32:56.719 0000][53678][gc             ] GC(6768763) Pause Young (Allocation Failure) 28027M->26484M(51008M) 77.596ms
[2020-10-27T04:33:29.488 0000][53678][gc,start       ] GC(6768764) Pause Young (Allocation Failure)
[2020-10-27T04:33:29.740 0000][53678][gc             ] GC(6768764) Pause Young (Allocation Failure) 28015M->26516M(51008M) 251.447ms
  

Ответ №1:

Важно отметить, что, если вы получили эту статистику из API CAT elasticsearch threadpool, тогда он показывает только данные на момент времени и не отображает исторические данные за последние 1 час, 6 часов, 1 день, 1 неделю подобным образом.

И отклоненный и завершенный — это статистика последнего перезапуска узлов, так что это также не очень полезно, когда мы пытаемся выяснить, становятся ли некоторые узлы ES горячими точками из-за плохой / несбалансированной конфигурации сегментов.

Итак, здесь нам нужно выяснить две очень важные вещи

  1. Убедитесь, что мы знаем фактические узлы горячих точек в кластере, просмотрев среднее количество активных, отклоненных запросов на узлах данных по диапазону времени (вы можете просто проверить часы пик).
  2. Как только узлы hotspot известны, посмотрите на выделенные им сегменты и сравните их с сегментами других узлов, несколько показателей для проверки, количество сегментов, сегменты получают больше трафика, сегменты получают самые медленные запросы и т. Д., И снова большинство из них вам нужно выяснить, просмотрев различные показатели и APIES, что может занять очень много времени и требует больших внутренних знаний ES.