Wie behebe ich einen hohen JVM-Speicherdruck in meinem OpenSearch Service-Cluster?
Mein Amazon OpenSearch Service-Cluster hat einen hohen JVM-Speicherdruck, und ich weiß nicht, wie ich das lösen kann.
Kurzbeschreibung
Standardmäßig verwendet OpenSearch Service 50 % des RAM einer Instance für JVM-Heaps mit einer Größe von bis zu 32 GiB. Der JVM-Speicherdruck gibt den Prozentsatz des Java-Heaps in einem Clusterknoten an. Die folgenden Richtlinien geben an, was die prozentualen Werte für den JVM-Speicherdruck bedeuten:
- Wenn der JVM-Speicherdruck 75 % erreicht, initiiert OpenSearch Service den Concurrent Mark Sweep (CMS) Garbage Collector für x86-Instance-Typen von Amazon Elastic Compute Cloud (Amazon EC2). ARM-basierte Graviton Amazon EC2-Instance-Typen verwenden den Garbage-First (G1) -Garbage-Collector, der zusätzliche kurze Pausen und Heap-Defragmentierung verwendet. Die Garbage Collection ist ein CPU-intensiver Prozess. Wenn die Speichernutzung weiter zunimmt, können ClusterBlockException, JVM OutOfMemoryError oder andere Cluster-Leistungsprobleme auftreten. Weitere Informationen finden Sie unter Wiederherstellung nach einer kontinuierlichen hohen Verarbeitungslast.
- Wenn der JVM-Speicherdruck 30 Minuten lang 92 % übersteigt, blockiert OpenSearch Service alle Schreibvorgänge.
- Wenn der JVM-Speicherdruck 100 % erreicht, ist die OpenSearch Service-JVM so konfiguriert, dass sie beendet wird und schließlich bei OutOfMemory (OOM) neu gestartet wird.
Die folgenden Gründe können zu einem hohen JVM-Speicherdruck führen:
- Erhöhte Anzahl der Anforderungen an den Cluster.
- Aggregationen, Platzhalter und Auswahl breiter Zeitbereiche in den Abfragen.
- Unausgeglichene Shard-Zuweisungen zwischen Knoten oder zu viele Shards in einem Cluster.
- Explosionen bei Felddaten oder Indexzuordnungen.
- Instance-Typen, die eingehende Lasten nicht verarbeiten können.
Auflösung
Reduzieren Sie den Datenverkehr zum Cluster, um Probleme mit hohem JVM-Speicherdruck zu lösen. Gehen Sie wie folgt vor, um den Datenverkehr zum Cluster zu reduzieren:
- Löschen Sie den Felddaten-Cache mit dem API-Vorgang POST /index\ _name/\ _cache/clear?fielddata=true.
**Hinweis:**Das Löschen des Caches kann laufende Abfragen unterbrechen. - Aggregieren Sie keine Textfelder und ändern Sie den Zuordnungstyp nicht in „Schlüsselwort“.
- Skalieren Sie die Domain so, dass die maximale Heap-Größe pro Knoten 32 GB beträgt.
- Aktivieren Sie langsame Protokolle (OpenSearch-Website), um fehlerhafte Anforderungen zu ermitteln.
**Hinweis:**Stellen Sie sicher, dass der JVM-Speicherdruck unter 90 % liegt. Weitere Informationen zu langsamen Elasticsearch-Abfragen finden Sie auf der Elasticsearch-Website unter Erweitertes Tuning: Finden und Beheben langsamer Elasticsearch-Abfragen. - Wählen Sie die richtige Anzahl von Shards, um die Suche oder Indizierung zu optimieren. Weitere Informationen zur Indizierung und Shard-Anzahl finden Sie unter Wie kann ich die ungleichmäßige Shard-Verteilung in meinem Amazon OpenSearch Service-Cluster ausgleichen?
- Löschen Sie alte oder ungenutzte Indizes, um die Anzahl der Shards zu reduzieren.
- Fortgeschrittene Benutzer können die Cache-Zuweisung für das übergeordnete Feld aktualisieren oder die Schutzschalter-Einstellungen entsprechend Ihrem Anwendungsfall anfordern. Weitere Informationen zu JVM-Schutzschaltern finden Sie unter JVM OutOfMemoryError.
Weitere Informationen zum Beheben eines hohen JVM-Speicherdrucks finden Sie unter Warum ist mein OpenSearch Service-Knoten abgestürzt?
Ähnliche Informationen
Fehlerbehebung bei Amazon OpenSearch Service
Wie kann ich eine Amazon OpenSearch Service-Domain hochskalieren oder aufskalieren?
Beginnen Sie mit Amazon Elasticsearch Service: Wie viele Shards benötige ich?
Relevanter Inhalt
- AWS OFFICIALAktualisiert vor 3 Jahren
- AWS OFFICIALAktualisiert vor einem Jahr
- AWS OFFICIALAktualisiert vor einem Jahr
- AWS OFFICIALAktualisiert vor 3 Jahren