Понимание формата журнала медленных запросов эластичного поиска

Question

У меня большой эластичный поисковый кластер с более чем 10 узлами данных, и там размещено несколько индексов с более чем 30 миллионами документов.

Теперь, чтобы устранить проблему с производительностью в этом кластере, я начал искатьв медленные журналы для некоторых индексов и заметил ниже странную вещь:

types [estype], stats [], search_type [QUERY_THEN_FETCH], total_shards [48], ,

Здесь мои медленные журналы показывают, что он поражает 48 шардов, что просто невозможно для моего индекса, поскольку он имеет 6 основных шардов с 3 репликами , и, как упоминалось в типе поиска, это обычный поискзапрос, согласно моему пониманию, для поискового запроса ES отправит запрос либо первичному сегменту, либо реплике реплики, но не обоим .

Таким образом, в соответствии с этой логикой максимальный удар должен составлять максимум 6 осколков, и даже если я считаю, что он поражает все осколки (включая реплики), то также может быть максимум 6 * 4 = 24 осколка, тогдапочему в моих медленных журналах он приходит как 48, и это вызывает у меня сомнения относительно медленности этих запросов.

Примечание: - Если я просто возьму запрос ES из медленного журнала и сразу нажму, используя kopf или curl, в ответе отображается только правильное количество шардов.

Answer 1

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

Когда я проверял в своем приложении, быловсего 8 языковых индексов (каждый из которых имеет 6 основных сегментов).

Запрос, который мы отправили в ES, использует (*) в имени индекса. У нас есть шаблон имени индекса как indexprefix_lang, так что foo_en, foo_gb,foo_es и так далее, поэтому, задав префикс * в индексе, как здесь foo_* , мы попадаем на все индексы. что привело к 8 * 6 = 48 осколков .

Причина путаницы заключалась в том, что другие языковые индексы, кроме английского, имели очень небольшое количество документов и не пересекали порог медленного запроса, установленный нами, и в формате журнала медленного запроса он показывает имя индексакоторый был foo_en, но он показывает total_shards для всего запроса независимо от индекса, который в этом случае будет 48.