Blog 
In 7 Schritten zur optimalen HugePages Konfiguration für Ihren Oracle Datenbankserver

Hugepages und Large Pages

Wenn Sie eine Oracle Datenbank auf einem Linux Server mit mehr als 16 GB physical Memory betreiben und die System Global Area (SGA) größer als 8 GB ist, sollten Sie HugePages konfigurieren. Oracle verspricht durch diesen Schritt eine höhere Performance. Eine HugePages Konfiguration bedeutet, dass der Linux Kernel mit „large pages“, wie Oracle sie allgemein nennt umgehen kann. Also statt der Standard 4 KB auf x86 und x86_64 oder 16 KB auf IA64 Systemen, dann mit 4 MB auf x86, 2 MB auf x86_64 und 256 MB auf IA64 System. Größere Pages bedeuten, dass das System weniger Page Tables benutzen, weniger Mappings verwalten muss, und so den Aufwand für deren Verwaltung und die Zugriffe reduziert werden.

Allerdings gibt es eine Einschränkung seitens Oracle, denn Automatic Memory Management unterstützt leider keine HugePages. Sollten Sie Automatic Memory Management (AMM) benutzen, also haben MEMORY_TARGET gesetzt, müssen Sie es an dieser Stelle abschalten und wieder auf Automatic Shared Memory Management (ASMM) umstellen, also wieder SGA_TARGET und PGA_AGGREGATE_TARGET setzen. Des Weiteren gibt es noch eine Neuerung namens Transparent Hugepages (THP), welche ausgeschalten werden sollte. Sie werden in einem Red Hat Linux ab Version 6 oder einem entsprechenden Derivat mitgeliefert. Sowohl Oracle als auch Red Hat empfehlen die Abschaltung von THP. Erklärung dazu in Punkt 5 – Serverkonfiguration ändern. Kommen wir also zur optimalen Konfiguration in 7 Schritten:

1. Physical Memory prüfen

Zunächst sollten wir unseren aktuellen „physikalisch“ verfügbaren Arbeitsspeicher überprüfen. Im Beispiel haben wir also knapp 128 GB RAM. SGA_TARGET und PGA_AGGREGATE_TARGET zusammen, sollten nicht größer als der vorhandene Arbeitsspeicher sein. Zudem sollte ausreichend Speicher für OS Prozesse selbst zur Verfügung stehen:

grep MemTotal /proc/meminfo

MemTotal: 132151496 kB

2. Datenbankparameter prüfen

Im zweiten Schritt überprüfen wir unsere Datenbankparameter. Zunächst: AMM ausgeschalten? MEMORY_TARGET und MEMORY_MAX_TARGET sollten auf 0 stehen:

SQL> select value from v$parameter where name = 'memory_target';

VALUE
---------------------------
0 

Wie groß ist unsere SGA? In diesem Beispiel knapp 40 GB. Wichtig: In der nachfolgenden Abfrage wird direkt in kB umgerechnet (value/1024). Sodass man mit diesem Wert anschließend weiter rechnen kann:

SQL> select value/1024 from v$parameter where name = 'sga_target';

VALUE
---------------------------
41943040

Schließlich sollte per Default der Parameter use_large_pages in der Datenbank eingeschalten sein:

SQL> select value from v$parameter where name = 'use_large_pages';

VALUE
---------------------------
TRUE

3. Hugepagesize prüfen

In unserem Beispiel verwenden wir einen x86_64 Red Hat Enterprise Linux Server. Also sollte per default die Hugepagesize auf 2 MB gesetzt sein:

grep Hugepagesize /proc/meminfo

Hugepagesize:       2048 kB

4. Hugepages kalkulieren

Für die Kalkulation der Anzahl der Hugepages gibt es eine einfache Faustformel:

SGA / Hugepagesize = Anzahl Hugepages

Also unserem Beispiel folgend:

41943040 / 2048 = 20480

Betreibt man auf einem Server mehrere Datenbanken, so sollte man in die Berechnung die SGA aller Instanzen einbeziehen. Also:

( SGA 1. Instanz + SGA 2. Instanz + … etc. ) / Hugepagesize = Anzahl Hugepages

Alternativ bietet Oracle unter der Doc ID 401749.1 auch ein Skript namens hugepages_settings.sh an, welches die entsprechende Berechnung vornimmt. Dieses bezieht auch eine Prüfung der Kernel Version und die aktuell verwendeten Shared Memory Bereiche durch das SGA ein. Beachten sollte man, dass sich die Berechnung auf die aktuelle SGA Größe und Verwendung bezieht. Das heißt also erst SGA anpassen, Datenbank durchstarten und dann das Skript ausführen. Ergebnis sollte dann folgender Satz sein. Überprüfen Sie doch einfach einmal Ihre Berechnung mit dem Ergebnis des Skripts:

Recommended setting: vm.nr_hugepages = 20480

5. Serverkonfiguration ändern

Im nächsten Schritt müssen wir die Anzahl der Hugepages im entsprechenden Server config-File eintragen. Dafür benötigen Sie root Berechtigungen. Unter Red Hat Linux 6 /etc/sysctl.conf

vi /etc/sysctl.conf

vm.nr_hugepages=20480

Richtig eingetragen, sollte folgendes Ergebnis zurückgeliefert werden:

grep vm.nr_hugepages /etc/sysctl.conf

vm.nr_hugepages=20480

Als weiteres müssen wir in der /etc/security/limits.conf die Parameter hard und soft memlock für den oracle User eintragen. Diese Werte sollten kleiner als der verfügbare Speicher in kB sein. Mindestens sollten aber unsere SGA bzw. unsere Hugepages hineinpassen. Daraus ergibt sich folgende Berechnung:

Anzahl Hugepages * Hugepagesize = minimum Memlock

Dem Beispiel folgend:

20480 * 2048 = 41943040
vi /etc/security/limits.conf

oracle               soft    memlock 41943040
oracle               hard    memlock 41943040

Richtig eingetragen, sollte folgendes Ergebnis zurückgeliefert werden:

grep oracle /etc/security/limits.conf

...
oracle               soft    memlock 41943040
oracle               hard    memlock 41943040

Wie bereits angesprochen müssen wir ab Red Hat Linux 6 Transparent Hugepages ausschalten:

cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
[always] madvise never

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag

cat /sys/kernel/mm/redhat_transparent_hugepage/enabled
always madvise [never]

6. Server Reboot

Haben Sie alle Parameter gesetzt starten Sie den Server komplett durch. Alternativ kann man mit sysctl -p die Parameter auch für den laufenden Server aktivieren.

 

7. Konfiguration überprüfen

Sitzt memlock korrekt?

ulimit -l
41943040 

Sind HugePages richtig konfiguriert und auch in Nutzung?

grep Huge /proc/meminfo

AnonHugePages:    538624 kB 
HugePages_Total:    20480
HugePages_Free:     12292
HugePages_Rsvd:      8188
HugePages_Surp:        0
Hugepagesize:       2048 kB

Sind Transparent Hugepages ausgeschalten?

cat /sys/kernel/mm/redhat_transparent_hugepage/enabled

always madvise [never] 

Nutzt die Datenbank HugePages? Dazu schauen wir uns das Alert Log an. Nach dem „Starting ORACLE instance (normal)“ sollte als folgender Eintrag „Large Pages Information“ zu finden sein:

************************ Large Pages Information *******************

Per process system memlock (soft) limit = 100 GB
Total Shared Global Region in Large Pages = 40 GB (100%)
Large Pages used by this instance: 20481 (40 GB)
Large Pages unused system wide = 0 (0 KB)
Large Pages configured system wide = 20481 (40 GB)
Large Page size = 2048 KB

******************************************************************** 

Bei einer Fehlkonfiguration gibt Oracle an dieser Stelle auch Empfehlungen für die richtige Konfiguration. Im nachfolgenden Beispiel fehlt eine einzige Page, also 2048 kB memlock um 100% des SGA als Hugepages zu allokieren:

************************ Large Pages Information *******************
...
...
RECOMMENDATION:

Total System Global Area size is 40 GB. For optimal performance,
prior to the next instance restart:
1. Increase the number of unused large pages by
at least 1 (page size 2048 KB, total size 2048 KB) system wide to
get 100% of the System Global Area allocated with large pages
2. Large pages are automatically locked into physical memory.
Increase the per process memlock (soft) limit to at least 40 GB to lock
100% System Global Area's large pages into physical memory

********************************************************************

Fertig!

4 Kommentare zu “In 7 Schritten zur optimalen HugePages Konfiguration für Ihren Oracle Datenbankserver

Hallo Sebastian,
wichtig:
Falls systemd zum Starten der instanz verwendet wird, wird limits.conf und damit die configurierten ulimits des „oracle“ Users ignoriert.
Daher muß in das service.unit File noch
LimitMEMLOCK=infinity
LimitNOFILE=65535+
aufgenommen werden.

Siehe:
https://bugzilla.redhat.com/show_bug.cgi?id=754285
https://oracle-base.com/articles/linux/linux-services-systemd

Viele Grüße
Peter

Vielen Dank für die Ergänzung!

Hallo Sebastian,
danke für die Erklärung, vielleicht kannst du noch eine Frage beantworten.
Nimmt sich der Parameter pga_aggregate_limit den Memory aus den konfigurierten HugePages oder bedient sich dieser aus dem verbleibenden physischen Memory?

Vielen Dank

LG
Harald

Hallo Harald,
nein, der Parameter pga_aggregate_limit bzw. pga_aggregate_target wird nicht aus dem Memory der Hugepages genommen, sondern aus dem „normalen“ Memory.
Gruß
Johannes Ahrends

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Was kann CarajanDB für Sie tun?