OpenSearch
OpenSearch ist eine der zentralen Systemkomponenten des BPC.
|
Die Dokumentation des Herstellers finden Sie unter https://opensearch.org/docs/latest/ |
Konfiguration
Arbeitsspeicher (RAM)
Die Höhe des zugewiesenen Arbeitsspeichers wird über die Umgebungsvariable OPENSEARCH_JAVA_OPTS gesetzt.
Diese Umgebungsvariable wird auch bei Verwendung der zentralen Konfiguration über bpc.env.sh genutzt.
Alternativ können auch die opensearch/config/jvm.options innerhalb der Installation verändert werden.
Siehe auch https://opensearch.org/docs/latest/install-and-configure/install-opensearch/index/
Bitte auch die Arbeitsspeicher-Beispiele für die zur Verfügung stehende Hardware unter Systemanforderungen beachten.
Ressourcen Limits
Auf UNIX basierten Betriebssystemen gibt es diverse Ressourcen Limits für Prozesse. Damit OpenSearch richtig arbeiten kann, müssen diese in der Regel erweitert werden.
Dazu ist die Datei /etc/security/limits.conf zu bearbeiten und um folgende Zeile zu ergänzen.
Dabei ist BPCUSER auf den Usernamen zu ändern, der den OpenSearch-Prozess startet.
BPCUSER - nofile 65535
Shards und Replicas von Indices
Dies sind die beiden Einstellungen eines Index, welche immer wieder für Probleme und Verwirrung sorgen.
Dies ist ein komplexes Thema und es gibt keine 100 % Lösung wie die Einstellungen number_of_shards und number_of_replicas je Index eingestellt werden sollten.
Zur Auffrischung was Replica und Shard sind:
Replica
-
Sind die "Sicherheitskopien" von Shards, wenn ein Node im Cluster ausfallen sollte.
-
Die Anzahl der Replicas kann auf 0 gesetzt werden. Dies macht aber nur bei einem Single Node bzw. Entwicklungssystem Sinn.
-
In einem OpenSearch Cluster mit >= 2 Nodes sollte dieser Wert auf mind. 1 gesetzt werden. So dass auf einem weiteren Node im Cluster eine Sicherheitskopie vorliegt.
Shard
-
Ein Shard enthält die Dokumente eines Index.
-
Ein Index kann aus 1 oder mehreren Shards bestehen.
-
Ein Shard kann ca. 50GB an Daten und ca. 200 Millionen Dokumente aufnehmen.
-
Größere Shards können bei Suchanfragen langsamer sein und im Fehlerfall länger zur Wiederherstellung brauchen.
-
Jeder Shard benötigt Heap Speicher.
-
Jeder Shard verwendet einen Thread.
Oversharding
Da jeder Shard Heap Speicher benötigt, ist der maximale Speicher der OpenSearch zur Verfügung gestellt wurde ein wichtiger Punkt, so dass es nicht zu Performanceproblemen kommt.
Das wird dann Oversharding genannt.
Es gibt eine Faustformel (Quelle) zur Errechnung der Anzahl Shards, bis zu der die Performance noch gut ist: Summe(Max Heap der Nodes in GB) * 20
Maximal Anzahl Shards
Das Maximum an Shards die im Cluster erzeugt werden können, ist in der Voreinstellung auf 1000 festgelegt.
Wird dieser Wert durch Anlegen weiterer Indices überschritten, dann kommt zu einem Fehler wie this action would add [5] total shards, but this cluster currently has [998]/[1000] maximum shards open;.
Lösungsmöglichkeiten:
-
Wenn auf den Nodes im Cluster genügend Heap Speicher zur Verfügung steht), dann kann das Limit wie folgt erhöht werden. Faustformel Beispiel: 3 Nodes je 32 GB Heap Speicher * 20 = 1920 Shards
curl -X PUT -H "Content-Type: application/json" 'http://localhost:9200/_cluster/settings' -d ' { "persistent": { "cluster.max_shards_per_node": 1920 } }'Kann zwar auch bei weniger Speicher erhöht werden, dann aber zulasten der Performance und sollte nur temporär erhöht werden.
-
Leere, nicht benutzte und geschlossene Indices löschen
-
Die Shards der vorhandenen Indices überprüfen und ggfs. durch einen Reindex reduzieren
