W pewnym momencie podczas testu obciążenia wytrzymałościowego 35K mojej aplikacji internetowej Java, która pobiera dane statyczne z ElasticSearch, zaczynam uzyskać wyjątek ElasticSearch:

Caused by: org.elasticsearch.common.util.concurrent.EsRejectedExecutionException: rejected execution of org.elasticsearch.common.util.concurrent.TimedRunnable@1a25fe82 on QueueResizingEsThreadPoolExecutor[name = search4/search, queue capacity = 1000, min queue capacity = 1000, max queue capacity = 1000, frame size = 2000, targeted response rate = 1s, task execution EWMA = 10.7ms, adjustment amount = 50, org.elasticsearch.common.util.concurrent.QueueResizingEsThreadPoolExecutor@6312a0bb[Running, pool size = 25, active threads = 25, queued tasks = 1000, completed tasks = 34575035]]

Elasticsearch Szczegóły :

Wersja ElasticSearch 6.2.4 .

Klaster składa się z 5 węzłów. Ustawienie rozmiaru sterty JVM dla każdego węzła to Xms16g i Xmx16g. Każda z węzła ma 16 procesorów.

Uwaga : Początkowo, kiedy dostałem ten wyjątek po raz pierwszy, postanowiłem zwiększyć parametr {x0}} w elasticsearch.yml, ustaw go na 10000. Tak, rozumiem, po prostu odłożyłem problem, aby się później.

Szczegóły WCZEŚNIEŃ ELSTASICSEarch: Obecnie jest około 20 interfejsów, a tylko 6 jest używany wśród nich. Niewykorzystany jest starych przypadków, które nie zostały usunięte po utworzeniu nowszych. Sama indeksy są naprawdę małe: Wprowadź opis obrazu tutaj

Indeks w czerwonym prostokącie jest indeks używany przez moją aplikację internetową. To są odłamki i ustawienia repliku są "Numer_of_shards": "5" i "Numer_of_pliki": "2" odpowiednio. Szczegóły odłamków: Wprowadź opis obrazu tutaj W tym Artykuł Znalazłem to

Małe odłamki powodują małe segmenty, co zwiększa nad głową. Celuj, aby utrzymać średni rozmiar odłamki między co najmniej kilku GB i kilkoma dziesiątkami GB. W przypadku przypadków użytkowania z danymi opartymi na czasach jest powszechny, aby zobaczyć odłamki między 20 GB do 40 GB.

Jak widać z powyższego zrzutu ekranu, mój rozmiar Shard jest znacznie mniejszy niż wymieniona wielkość. Stąd P: Jaka jest odpowiednia liczba odłamków w moim przypadku? Czy jest 1 lub 2 ? Indeks nie dorastał dużo czasu.

es zapytania wydane podczas testu. Testy obciążenia symuluje scenariusz, w którym użytkownik nawiguje na stronę do wyszukiwania niektórych produktów. Użytkownik może przefiltrować produkty za pomocą odpowiednich filtrów (dla np. Nazwa, miasta itp ...). Unikalne wartości filtra są pobierane z indeksu ES za pomocą zapytania kompozytowego. Jest to więc pierwszy typ zapytania. Innym zapytaniem jest pobieranie produktów z ES. Składa się z MUST_M>, MUST_NOT , HAS_Child Atrybut równa się 100.

Ustawiłem rejestrowanie powolnego wyszukiwania, ale nic nie zostało zalogowanego:

"index": {
                "search": {
                    "slowlog": {
                        "level": "info",
                        "threshold": {
                            "fetch": {
                                "debug": "500ms",
                                "info": "500ms"
                            },
                            "query": {
                                "debug": "2s",
                                "info": "1s"
                            }
                        }
                    }
                } 

Czuję, że brakuje mi czegoś prostego, aby wreszcie i mogło poradzić sobie z moim ładunkiem. Doceń, jeśli ktoś może mi pomóc w rozwiązaniu problemu.

2
I. Domshchikov 20 listopad 2020, 23:07

1 odpowiedź

Najlepsza odpowiedź

W przypadku takiego małego rozmiaru używasz 5 głównych odłamków, które czuję, ze względu na twoją wersję ES 6.x (domyślnie wynosił 5), a nigdy go nie zmieniłeś, ale krótko mówiąc o dużej liczbie pierwotnych odłamków dla małego indeksu, Ma ciężką karę wydajności, zapoznaj się z bardzo podobnym etui użytkowania (miałem również 5 ps 😀), które przykryłem Mój blog.

Jak już wspomniałeś, że twój rozmiar indeksu nie będzie się znacząco rozwijać w przyszłości, sugerowałbym mieć 1 pierwotne odłamki i 4 odłamki repliki

  1. 1 Primary Shard oznacza pojedyncze wyszukiwanie, tylko jeden wątek i jeden wniosek zostanie utworzony w ElasticSearch, zapewni to lepsze wykorzystanie zasobów.
  2. Ponieważ masz 5 węzłów danych, mający 4 repliki, odłamki są prawidłowo rozprowadzane na każdym węźle danych, więc przepustowość i wydajność będą optymalne.

Po tej zmianie zmierzyć wydajność, a ja jestem pewien po tym, możesz ponownie skrócić rozmiar kolejki wyszukiwania do 1K, jak wiesz, że posiadający wysoki rozmiar kolejki jest po prostu opóźniający problem i nie dotyczy problemu pod ręką.

Przyjście do wyszukiwania Powolny dziennik, czuję, że masz bardzo wysoki próg, do fazy zapytania {X0}} dla zapytania jest naprawdę wysokie dla aplikacji w obliczu użytkownika, spróbuj obniżyć ~ 100ms i nie w dół tych zapytań i Zoptymalizuj je dalej.

1
Opster Elasticsearch Ninja 21 listopad 2020, 06:05