Unbalanced Elasticsearch Leistung

Question

Wir haben ein Elasticsearch Cluster mit 9 Knoten mit den folgenden Einstellungen:

• Elasticsearch Version 5.1.2
• Ein Index in Cluster
• Primärsplitter Speichergröße: 3GB
• Anzahl von Scherben: 5
• Nummer des Replikats: 3
• Node-1, Node-2 und Node-3 nur Master Nodes
• Knoten-4 bis Knoten-9 Data Only Knoten
• Nein Eltern Kind Beziehung in Mappings
• Jeder Knoten 24 GB Ram, 18 Cores von CPU
• Disabled swaped, Erhöhte Open File Descriptor, 12 GB JVM Heap Speicher
• Nest-Client ‚Static‘ Adapter und eine Liste aller Knoten IPs

Wie Sie sehen wir haben eine über Zuweisung von Ressourcen auf unsere Knoten aber unter Stress-Test nur ein Knoten alle verwendet es verfügbar Suche Threads. Wie ich bereits erwähnt habe, haben wir 18 Kerne und entsprechend der Standard-Such-Thread-Grenze haben wir (3 * 18/2) +1 = 28 Such-Threads in jedem Knoten.
Probleme:

• HTTP-Anforderungen Nicht Balanced
• Andere Knoten, die alle ihre Suche nicht Threads verwenden. Ein Knoten verwendet Es ist alle Threads und es ist Suche Warteschlange groß wird

Was haben wir getestet:
- Verwenden Sie einen Koordinatorknoten zu balancieren Anforderungen (keine Änderung)
Wie wir Anfragen senden:
- Wir verwenden Elasticsearch als Suchmaschine und Jmeter wird verwendet, um Stresstest auf Suchdienste zu setzen. Prüfdienstleistungen sind Web-Services, die Elasticsearch Nest Client

Jede Idee ist willkommen mit einigen SearchTemplates nennen.

Answer 1

Haben Sie einen Lese von https://www.elastic.co/guide/en/elasticsearch/client/net-api/current/connection-pooling.html

Sieht aus wie Sie die SingleNodeConnectionPool verwenden, die verwendet wird, wenn Sie die niedrigen Zeremonie verwenden ElasticClient, das heißt var client = new ElasticClient(uri); In diesem Fall werden alle Ihre Anfragen an einen Knoten gesendet werden, die als Coordinator node hier beschrieben handeln muss:

zum Beispiel https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html

Eine Suchanfrage, in zwei Phasen ausgeführt wird, die sind koordiniert von dem Knoten, der die Client-Anfrage empfängt - die koordinierenden Knoten.

In der Streuphase leitet der koordinierende Knoten die Anforderung an die Datenknoten, die die Daten enthalten, an weiter. Jeder Datenknoten führt die Anforderung lokal aus und gibt seine Ergebnisse an den koordinierenden Knoten zurück. In der Sammelphase reduziert der koordinierende Knoten die Ergebnisse jedes Datenknotens in eine einzige globale Ergebnismenge.

Jeder Knoten ist implizit ein koordinierender Knoten. Dies bedeutet, dass ein Knoten , bei dem alle drei Knoten "node.master", "node.data" und "node.ingest" auf "false" gesetzt sind, nur als koordinierender Knoten fungiert, der nicht deaktiviert werden kann. Als ein Ergebnis, muss ein solcher Knoten genug Speicher und CPU haben, um mit der Sammelphase zu beschäftigen.

StaticConnectionPool oder SniffingConnectionPool wäre eine bessere Wahl für den Cluster sein.