Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- elo:esearch_crashes [2026/01/16 13:28] – 213.208.157.29
+++ elo:esearch_crashes [2026/02/24 17:49] (aktuell) – 84.20.184.166
@@ Zeile 4: / Zeile 4: @@
   * die Indizesgröße ist zu groß für den Arbeitsspeicher (eher selten außer bei Kunden > 1000 Benutzer oder einer äquivalenten Menge an Dokumenten/Ordner im Index)
-  * zu viel Memory-Pressure vom VM-Host/Virtualisierungs-Host (hier versuchen teilweise die Virtualisierer Speicher zu überbuchen oder zu sharen und diese Mechanismen sind teilweise eher sehr Microsoft-optimiert)
+    * Abhilfe: hier wirds dann wirklich tricky. Clustering abweichend vom Standard ist möglicherweise notwendig.
-  * Hardware-Probleme
+  * zu viel Memory-Pressure vom VM-Host/Virtualisierungs-Host (bei Hyper-V bspw. Dynamic Memory, hier versuchen teilweise die Virtualisierer Speicher zu überbuchen oder zu sharen und diese Mechanismen sind teilweise eher bedingt durch den Einsatz von Windows sehr Microsoft-optimiert)
+    * Abhilfe: den Virtualisierungsadministrator einmal bitten zu prüfen, ob hier Memory-Sharing passiert, ggf. Speicher an der VM anheben und exklusiv garantieren lassen. Kein einfaches Thema per se,
+  * Hardware-Probleme (eher selten)
+    * Defekter RAM (eher ganz selten)
+    * Defekte I/O (HDD oder Controller)
+  * Memory-Hogger: bspw. TeamViewer und Co. die sukzessive Speicher aufbauen können und in so lange nicht freigeben, solange die User-Session dauert etc.
 Das Unangenehme bei ElasticSearch Crashes ist hier immer noch, dass der Hersteller keine Mechanismen zur konsistenten Snapshot Sicherung vorsieht (hier müsste per NEST oder Java API die Elastic angehalten werden, eine Sicherung an einen Backup Ort durchzuführen). Ein Rückgriff auf die gesicherten Dateien eines regulären Backups (bspw. Veeam etc.) ist in der Regel mit dem Risiko behaftet, dass hier "inkonsistente" Backups restort werden. Somit ist der primäre Weg, es sei denn man legt hier Programmierung für eine eigene Sicherungsroutine an, die Neuinstallation der ESearch Datenbasis mittels Serversetup.
+===== Neuinstallation ESearch =====
+Ein durchaus möglicher Weg, der hier mit Version 23 LTS getestet werden konnte (Ende 2025 Serversetup) ist hier folgender Weg:
+  * Beenden der Dienste
+    * Danach die MMC mit der Dienstliste schließen auch den TaskManager um die Service-Handles freizugeben
+  * Löschen des Dienstes (mit der Endung -iSearch, sc delete <ServiceName>)
+  * Umbennenen / Löschen des ISearch Datenordners
+  * Umbennenen / Löschen des ISearch Konfigurationsordners
+  * Kontrolle ob der Dienst gelöscht ist, ggf. Neustart durchführen des Servers, wenn das Service Handle noch gesperrt ist und der Dienst noch nicht vollständig gelöscht ist.
+  * Serversetup neu ausführen
 ===== Neuinstallation ESearch im Vergleich zu Leeren des Index Ordners =====
@@ Zeile 21: / Zeile 38: @@
   * ggf. den Dienst mit sc delete entfernen
   * danach neu installieren
+===== Manuelle Installation des SearchGuard =====
+Der SearchGuard kann hier auch manuell installiert werden. Hier sollte man den Output beim Serversetup beachten. Bei einer Neuinstallation kommt hier ein eigener Befehl zum Einsatz. Die ESearch muss hier zu diesem Zeitpunkt bereits laufen. Dies kann dann eine Neuinstallation über das Serversetup überflüßig machen.