Solr wydaje się blokować żądania aktualizacji podczas popełniania

Question

Biegniemy do konfiguracji master-slave z Solr 3.6 przy użyciu następujących opcji auto-commit:

maxDocs: 500000

MaxTime: 600000

Mamy w naszym indeksie znajduje się około 5 milionów dokumentów, które zajmują około 550 GB. Pracujemy zarówno nad master, jak i slave na instancjach Amazon EC2 XLarge (4 wirtualne rdzenie i 15 GB). Nie mamy szczególnie wysokiej przepustowości zapisu - około 100 nowych dokumentów na minutę.

Używamy Jetty jako kontenera, który ma przydzielone 6 GB.

Problem polega na tym, że po rozpoczęciu zatwierdzania wszystkie nasze żądania aktualizacji zaczynają się wyczerpywać (nie wykonujemy kwerend dotyczących tego pola). Wydaje się, że samo zatwierdzenie trwa około 20-25 minut, podczas których nie możemy dodać nowych dokumentów do Solr.

Jedna z odpowiedzi w poniższym pytaniu sugeruje użycie 2 rdzeni i zamianę ich po ich pełnej aktualizacji. Jednak wydaje się to trochę przesadzone.

Solr requests time out during index update. Perhaps replication a possible solution?

Czy jest coś innego, co powinno być patrząc na czasowo dlaczego Solr wydaje się być wnioski blokujące? Jestem optymistycznie nadzieję istnieje „dontBlockUpdateRequestsWhenCommitting” flagi w config, że mam wychodził ...

Dziękujemy,

Answer 1

Według nagród rozumu i problemu wymienionego w pytaniu o to rozwiązanie z Solr:

Solr ma zdolność, która jest nazywana jako SolrCloud począwszy od wersji 4.x Solr. Zamiast poprzedniej architektury master/slave istnieją liderzy i repliki. Przywódcy są odpowiedzialni za indeksowanie dokumentów i replik odpowiedzi na pytania. Systemem zarządza Zookeeper. Jeśli lider schodzi w dół, jeden z jego replik zostaje wybrany jako nowy lider.

W sumie, jeśli chcesz podzielić proces indeksowania, który jest w porządku z SolrCloud automatycznie, ponieważ istnieje jeden lider dla każdego odłamka i są one odpowiedzialne za indeksowanie ich dokumentów z shardu. Kiedy wyślesz zapytanie do systemu, pojawi się kilka węzłów Solr (oczywiście jeśli istnieją węzły Solr bardziej niż liczba odłamków), które nie są odpowiedzialne za indeksowanie, ale gotowe do odpowiedzi na zapytanie. Gdy dodasz więcej repliki, uzyskasz szybszy wynik zapytania (ale spowoduje to większy ruch przychodzący w sieci podczas indeksowania itp.)

Answer 2

Dla tych, którzy stoją przed podobnym problemem, przyczyną mojego problemu było posiadanie zbyt wielu pól w dokumencie użyłem pól automatycznych * _t, a liczba pól rośnie dość szybko, a kiedy osiągnie określoną liczbę, po prostu świń solr i commit będzie trwał wiecznie.

Po drugie, wziąłem trochę wysiłku, aby wykonać profilowanie, to w końcu większość czasu jest zużywana przez funkcję string.intern(), wydaje się, że liczba pól w dokumencie ma znaczenie, kiedy liczba ta rośnie, string.intern() wydaje się wolniej.

Źródło solr4 wydaje się już nie używać string.intern(). Ale duża liczba pól nadal dość łatwo zabija wydajność.