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 jvm.options innerhalb der Installation verändert werden.

Siehe auch https://opensearch.org/docs/latest/install-and-configure/install-opensearch/index/

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

Siehe auch https://opensearch.org/docs/latest/install-and-configure/install-opensearch/index/#important-settings

Swapping

Swapping sollte auf dem System möglichst vermieden werden, da dies die Leistung stark einschränkt.

Die Einstellung für das Swapping hängt von Ihrem Betriebssystem ab.

Siehe auch https://opensearch.org/docs/latest/install-and-configure/install-opensearch/index/#important-settings

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
```
[source,bash]
----
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

Keywords: