ElasticSearch BulkShardRequest ist aufgrund von org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor fehlgeschlagen

Abdul Basith

Ich speichere Protokolle in der elastischen Suche aus meiner reaktiven Federanwendung. Ich erhalte den folgenden Fehler bei der elastischen Suche:

Elasticsearch-Ausnahme [Typ = es_rejected_execution_exception, Grund = abgelehnte Ausführung der Verarbeitung von [129010665] [Indizes: Daten / Schreiben / Bulk [s] [p]]: Anforderung: BulkShardRequest [[logs-dev-2020.11.05] [1]] enthält [index {[logs-dev-2020.11.05] [_ doc] [0d1478f0-6367-4228-9553-7d16d2993bc2], Quelle [n / a, tatsächliche Länge: [4,1 kb], maximale Länge: 2 kb]}] und eine Aktualisierung, Zielzuordnungs-ID: WwkZtUbPSAapC3C-Jg2z2g, primärer Begriff: 1 in EsThreadPoolExecutor [Name = 10-110-23-125-common-elasticsearch-apps-dev-v1 / write, Warteschlangenkapazität = 200, org.elasticsearch.common .util.concurrent.EsThreadPoolExecutor @ 6599247a [Wird ausgeführt, Poolgröße = 2, aktive Threads = 2, Aufgaben in der Warteschlange = 221, abgeschlossene Aufgaben = 689547]]]

Meine Indexeinstellungen:

{
        "logs-dev-2020.11.05": {
        "settings": {
            "index": {
                "highlight": {
                    "max_analyzed_offset": "5000000"
                },
                "number_of_shards": "3",
                "provided_name": "logs-dev-2020.11.05",
                "creation_date": "1604558592095",
                "number_of_replicas": "2",
                "uuid": "wjIOSfZOSLyBFTt1cT-whQ",
                "version": {
                "created": "7020199"
                }
            }
        }
    }
}

Ich habe diese Seite durchgesehen:

https://www.elastic.co/blog/why-am-i-seeing-bulk-rejections-in-my-elasticsearch-cluster

Ich dachte, das Anpassen der "Schreib" -Größe im Thread-Pool wird sich auflösen, aber es wird auf der folgenden Site als nicht empfohlen erwähnt:

Das Anpassen der Warteschlangengrößen wird daher dringend empfohlen, da das Problem eher als vorübergehende Band-Hilfe behandelt wird, als das zugrunde liegende Problem tatsächlich zu beheben.

Was können wir also noch tun, um die Situation zu verbessern?

Andere Information:

  • Elastic Search Version 7.2.1
  • Der Clusterzustand ist gut und es handelt sich um 3 Knoten im Cluster
  • Der Index wird täglich erstellt, es gibt 3 Shards pro Index
Elasticsearch Ninja

Obwohl Sie Recht haben, dass das Erhöhen der Größe von thread_pool keine dauerhafte Lösung ist, werden Sie froh sein zu wissen, dass elasticsearch selbst die Größe von write thread_pool (Verwendung in Ihren Massenanforderungen) in nur einem geringfügigen Versions-Upgrade von 200 auf 10.000 erhöht hat. Bitte sehen Sie die Größe von 200 in ES 7.8 , während 10k von ES 7.9 .

Wenn Sie die ES 7.X-Version verwenden, können Sie die Größe auch auf 10 KB und dann auf mindestens 1 KB erhöhen (um zu vermeiden, dass die Anforderungen abgelehnt werden).

Wenn Sie eine ordnungsgemäße Lösung wünschen, müssen Sie die folgenden Schritte ausführen

  1. Finden Sie heraus, ob es konsistent ist oder nur ein kurzzeitiger Burst von Schreibanforderungen, der in einiger Zeit gelöscht wird.
  2. Wenn es konsistent ist, müssen Sie herausfinden, ob die gesamte Schreiboptimierung vorhanden ist. Weitere Informationen zur Verbesserung der Indexgeschwindigkeit finden Sie in meinen Kurztipps .
  3. Überprüfen Sie, ob Sie die volle Kapazität Ihrer Datenknoten erreicht haben, und skalieren Sie Ihren Cluster, wenn ja, um die erhöhte / legitime Last zu bewältigen.

Verwandte Artikel