Ressourcenmanagement
Motivation
Neben dem Speicher, der für die DB zur Verfügung steht (DB RAM), verbraucht auch jeder SQL-Prozess auf jedem der Cluster-Knoten gewissen Heap-Speicher (z.B. im GROUP BY, Prefetching, …). Gerade bei vielen parallelen Nutzern wächst dieser Speicher unter Umständen derart, dass auf den Cluster-Knoten der physikalische Speicher nicht mehr ausreicht und das Betriebssystem beginnt, Speicher auf die Festplatte auszulagern (Swapping).
Bei massivem Swap-Aufkommen reagiert der Knoten nahezu nicht mehr und wird von den anderen Knoten als ausgefallen gesehen. Die Folge sind System-Restarts und das Aufnehmen eines Ersatzknotens. Der „ausgefallene“ Knoten erholt sich in der Regel dann schnell und wird als neuer Ersatzknoten integriert.
Ressourcen-Management in EXASolution
Um den Speicherverbrauch zu begrenzen, wird die Ausführung von lang laufenden Queries geschedult. Die Anfragen werden kurzfristig angehalten und wieder gestartet. Am Gesamtdurchsatz ändert sich dadurch kaum etwas, da das Betriebssystem selbst die Prozesse unter Berücksichtigung der Anzahl CPU-Kerne auch anhalten müsste (Task-Switching vom Betriebssystem).
Steigt der tatsächliche Verbrauch über eine durch den Administrator definierte Grenze (Process Memory), so werden einerseits keine Queries mehr gestartet (auch kein Login mehr möglich!). Andererseits werden solange Prozesse mit dem meisten Speicherverbrauch abgebrochen (der Nutzer erhält eine Fehlermeldung), bis die Grenze wieder unterschritten wird.
Der verfügbare Prozess-Speicher kann in EXAoperation über den Parameter "Process memory per node" konfiguriert werden. Dieser definiert den für die SQL-Prozesse verfügbare Arbeitsspeicher (Heap).
Beispielkonfiguration:
- HW: 4 Knoten à 32GB RAM
- Memory: 100 GB Lizenz (also 25 GB pro Knoten)
- Process memory per node: (5 GB)
In der Beispielkonfiguration werden 25 von den 32 GB RAM für den Datenbankspeicher benutzt und 5 GB für die Prozesse reserviert. Die restlichen 2 GB sind Puffer fürs Betriebssystem.
Die Vorteile durch das Ressourcen-Management:
- Vermeidung einer Systemüberlastung
- Unterstützung von Mixed Workload:
Kleine Queries werden bevorzugt, wodurch der gefühlte Durchsatz steigt. Auch die Reaktionszeit kleiner Anfragen oder die Login-Dauer bei sehr hoher Systemlast verbessert sich deutlich.
Empfehlungen
- Parameter Process Memory per node initial einstellen:
Mit ca. 20-50 MB pro parallelem Nutzer sollte mindestens gerechnet werden - Beobachtung des Speicherverbrauchs:
Siehe System-Tabellen EXA_MONITOR_* mit den Spalten MEM_AVG bzw. MEM_MAX. Hiermit lässt sich der minimal benötigte Wert für den Parameter Process Memory per node gut bestimmen. Der Wert sollte allerdings stets einen Sicherheits-Puffer nach oben besitzen, um unnötige Queryabbrüche zu vermeiden. - Optimierung speicherlastiger Anfragen:
In den System-Tabellen EXA_SESSIONS (Spalte MEM_USAGE) und EXA_SQL_LAST_DAY (Spalte MEM_PEAK) erhalten Sie wertvolle Informationen, wie viel Speicher Ihre Anfrage gerade verbraucht bzw. verbraucht hat. Anfragen mit sehr viel Speicherverbrauch können evtl. optimiert werden, wobei wir Ihnen gerne helfen!
