SAP HANA Deepdive: Optimierung und Stabilität im Betrieb

2.1 KPI: Hauptspeicher

Die wichtigste Kennzahl im Sizing ist der Hauptspeicher (RAM). Um diesen Wert richtig zu deuten, ist es essenziell zu wissen, wie die HANA den RAM verwendet. Hiermit beschäftigen sich die nächsten Seiten.

2.1.1 Verwendung des Hauptspeichers durch HANA

Als Trainer im HANA-Umfeld hören wir in unseren Schulungen und Workshops häufig Aussagen, die nicht ganz der Wahrheit entsprechen. Etwa diese: »HANA hält immer alle Daten vollständig im Hauptspeicher.« Richtig ist: HANA hält die wichtigsten Daten im Hauptspeicher und kann nach Load- und Unload-Kriterien (inklusive Behandlung besonderer Cache-Bereiche, wie LOB-Cache) jederzeit Daten auslagern. Das gilt erst recht seit dem Einsatz von Data-Tiering-Techniken wie NSE (Native Storage Extension). Mit diesem Feature können selektiv Daten ausgelagert werden und bei Bedarf (=Datenzugriff) in einen Puffer (NSE Buffer Cache) geladen werden, der einen limitierten Speicherbereich im RAM einnimmt. Das Ziel dabei ist, den Puffer überzubelegen, sodass mehr Daten ausgelagert werden. Das Delta zwischen ausgelagerten Daten und Puffer ist die erzielte Einsparung an Hauptspeicher.

Oft hört man auch die Aussage: »Die Monitoringtools des Betriebssystems zeigen stetig einen hohen Hauptspeicherverbrauch an, und die HANA nimmt sich zu viel Speicher.« Richtig ist: Die HANA-Datenbank verwaltet den Speicher, den sie vom Betriebssystem anfordert, selbst und gibt ihn nur in bestimmten Situationen wieder zurück. Denn bereits allokierter und vordefinierter Speicher kann schnell wiederverwendet werden. Das spart Zeit, und meist laufen keine anderen nennenswerte Programme neben der HANA auf dem System. Daher empfehlen wir, sich nicht auf ein OS-Monitoring zu fokussieren und die richtigen KPIs in der HANA selbst zu monitoren.

Im HANA-Sprachgebrauch unterscheiden wir zwei RAM-Bereiche:

• Working Space oder auch Dynamic RAM
• Payload (Nutzdaten) oder auch Static RAM

Der Payload besteht aus den Tabellen (Column + Row Store) der Datenbank. Die Bezeichnung »Static« ist, wenn man das stetige Laden und Entladen der Tabellen betrachtet, nur bedingt zutreffend. Im Vergleich dazu ist die Begrifflichkeit »Dynamic« für den sogenannten Working Space mehr als zutreffend. Dabei handelt es sich um den Hauptspeicher, der nach Allokation von Betriebssystem, HANA Code & Stack und Nutzdaten übrig bleibt. In diesem per Definition sehr dynamischen Bereich werden alle SQL-Anfragen abgearbeitet. Operationen wie Sortieren und Gruppieren oder auch temporäre Ergebnismengen verwenden ebenso diesen fluktuierenden Teil des RAM, der in der Fachsprache auch als Heap bekannt ist. Als Heap wird alles in der HANA bezeichnet, was nicht dem »Shared Memory« zuzuordnen ist. All diese Details finden Sie in einem umfassenden Schaubild in Abbildung 2.1.

Abbildung 2.1: HANA Hauptspeicher Allokation

Von SAP wird eine 1:1-Verteilung auf die Bereiche Working Space (50%) und Payload (50%) empfohlen. Dies ist in den meisten Fällen sehr großzügig und erlaubt daher auch meistens einige Jahre an Wachstum. In der heutigen Zeit der Virtualisierung und des Cloud-Computings empfehlen wir aus Kostengründen, etwas restriktiver mit den Ressourcen umzugehen. Wenn der Workload bekannt ist und das Wachstum gut prognostiziert werden kann, tendieren wir zu einer Überallokation des Payload-Bereichs. Dies ist keine allgemeine Empfehlung, sondern abhängig vom jeweiligen Workload des Systems. In den meisten Szenarien ist eine Verteilung von 70% Nutzdaten zu 30% Working Space das Maximum im OLTP-Bereich, ohne die Stabilität zu gefährden.

Die grundlegende Frage ist: Wann sollte ein System neue Ressourcen erhalten? Auf der einen Seite darf auf keinen Fall die Stabilität gefährdet werden und ein Speicherengpass eintreten. Auf der anderen Seite stehen die Hardwarekosten. In letztlich nicht genutzte Ressourcen zu investieren, nur um für die nächsten fünf Jahre gerüstet zu sein, können wir aufgrund der schnellen Technologieentwicklung nicht empfehlen. Viel besser ist es, die richtigen Kennzahlen zu überwachen und frühzeitig Maßnahmen für ein Resizing zu ergreifen.

2.1.2 HANA-Resizing

Der Prozess eines Resizings ist in Abbildung 2.2 dargestellt.

Abbildung 2.2: HANA-Resizing

Sie erkennen die Aufteilung einer 2-TB-Zuweisung in 1 TB Nutzdaten und 1 TB Working Space. Nachdem der Payload den Schwellenwert von 65% erreicht hat, wurde ein Resizing auf 3 TB veranlasst. Das Wachstum von 300 GB auf 1,3 TB RAM hat bei einer 3-TB-Instanz zur Folge, dass die Tabellen nun 43% einnehmen. Die meisten Hoster oder Hyperscaler sind aber wie Modehändler: Sie bieten nur bestimmte »T-Shirt-Größen« an, sodass es immer zu einem größeren »Verschnitt« kommt. Versuchen Sie daher, falls möglich, in kleinen Schritten zu erweitern. Bedenken Sie bitte ebenfalls, dass die Summe aller Tabellen nicht immer das Nutzverhalten der Datenbank widerspiegelt. Wird bald ein großer Teil archiviert oder bringen Sie zusätzlich Features wie Native Storage Extension (NSE) mit ein, wird diese Methode des Peak Sizing nicht in der gewünschten Weise funktionieren. In der Herangehensweise der SAP sprechen wir von einem Peak Sizing, wenn vom schlimmsten Fall ausgegangen wird und alle Daten zu einem Zeitpunkt in den Hauptspeicher geladen und verarbeitet werden sollen. Dieses Szenario tritt nie ein und schützt lediglich vor einem zu klein dimensionierten System.

2.1.3 Wichtige Kennzahlen

Da das erwähnte Peak Sizing unter Umständen in die Irre führt, empfehlen wir eine effektivere Variante: die Kennzahlen für die Nutzung des Hauptspeichers mit dem Skript HANA_Memory_Components zu ermitteln (siehe Listing 2.1). Es zerlegt den Heap in die wichtigsten Bestandteile und zeigt die tatsächliche Allokation zu einem bestimmten Zeitpunkt an. Bitte beachten Sie, dass Sie sich mehrere Zeitpunkte ansehen sollten, um repräsentative Werte zu erhalten.

H_COL_GB: Heap memory consumed by component 'Column Store Tables' (GB) H_ROW_GB: Heap memory consumed by component 'Row Store Tables' (GB) H_SYS_GB: Heap memory consumed by component 'System' (GB), excluding NSE page cache (Pool/CS/BufferPage) H_NSE_GB: Heap memory consumped by NSE page cache (Pool/CS/BufferPage) H_STMT_GB: Heap memory consumed by component 'Statement Execution & Intermediate Results' (GB) H_CACHE_GB: Heap memory consumed by component 'Cache' (GB) H_MON_GB: Heap memory consumed by component 'Monitoring & Statistical Data' (GB) 

Listing 2.1: Ausgabeparameter HANA_Memory_Components

Sehen wir uns die Ausgabeparameter im Einzelnen an:

• H_COL_GB beschreibt dabei alle CS(Column-Store)-Tabellen. Diese sollten mit Abstand den größten Anteil in Ihrem System einnehmen und können je nach Verwendung vollständig geladen sein.
• H_ROW_GB steht für die RS(Row-Store)-Tabellen diese sind aufgrund ihres Designs immer zu 100% geladen, der Bereich kann nicht ausgelagert werden.
• Die Komponente H_SYS_GB beschränkt sich auf alle Allokatoren des SYSTEM-Bereichs.
• H_NSE_GB stellt den Cache für den bereits am Anfang des Abschnitts 2.1.1 erwähnten Puffer dar.
• H_CACHE_GB steht für alle weiteren Caches.
• Die Summe an allokiertem Speicher für alle im ausgewählten Zeitraum laufenden SQL-Abfragen spiegelt sich in der Komponente H_STMT_GB wider.
• Zu guter Letzt finden Sie mit der KPI in H_MON_GB Ihre gesammelten Statistik- und Monitoringdaten dargestellt, die sich zu diesem Zeitpunkt im Speicher befinden.

Dank dieser gesammelten Kennzahlen können Sie Ihr HANA-System in kleinere Komponenten zerlegen und gezielt große Bereiche mit Housekeeping verkleinern oder mit Daten aus weiteren Skripten noch weiter auf Objektebene herunterbrechen.

Andere Varianten können ebenfalls als Indikator herangezogen werden. Dazu zählen:

• Sizing Report
• HANA Cockpit
• EWA-Dashboard

Bitte hinterfragen Sie jedoch die daraus gewonnenen Kennzahlen und übernehmen Sie diese auf keinen Fall ungeprüft!