Linux Huge Pages: Schnellstart

If you’re not using HugePages, you’re doing it wrong!  (Mark J. Bobak)

Sie haben eine SGA von mehreren GB Größe, dazu mehrere Hundert Sessions auf der Datenbank? Ihr DB-Server läuft unter Linux, aber ohne Einsatz von HugePages? Dann verschenken Sie RAM und CPU-Leistung, und zwar nicht zu knapp!

Über Linux HugePages wurde schon viel geschrieben (s. Literaturliste unten), jedoch hauptsächlich auf Englisch und meist sehr ausgedehnt. Dieser Artikel soll die wichtigsten Fakten und Maßnahmen in Kürze aufzeigen.

Szenario

Ein Praxisbeispiel vorweg: Eine Data Warehouse-DB mit 20 GB SGA und etwa 300 Sessions läuft auf einem Server mit 32 GB RAM. Gelegentlich gerät der Server unter höhere Last und fängt daraufhin an, massiv zu swappen; die Performance geht in die Knie. Was ist passiert?

Für die Speicherverwaltung von Shared Memory werden sog. Page Tables verwendet, die unter Unix/Linux für jeden Prozess kopiert werden. Da der Server mit Speicherseiten von 4 kB Größe arbeitet, kommen wir bei 8 Byte pro Speicherseite für die Page Table auf:

20 GB / 4 kB * 8 Byte/Prozess * 300 Prozesse = 12 GB

12 GB nur für die Verwaltung des Speichers! Das klingt nach fortgeschrittener Bürokratie… ;-)

Erschwerend kommt hinzu, dass für das Scannen der Page Tables CPU-Leistung verbraucht wird, jedesmal, wenn ein Prozess auf eine Speicherseite zugreifen oder eine neue allokieren will. Jedesmal, wenn der Linux-Kernel nach wenig benutzten Speicherseiten sucht (s. Doc ID 361670.1). Jedesmal, wenn die CPU Teile der Page Table in ihren eigenen Cache („TLB„) laden muss. Eine Verschwendung von RAM und CPU-Zeit, die besser verwendet werden könnten.

Auftritt HugePages

HugePages sind unter Linux schon seit einigen Jahren verfügbar, haben aber immer noch den Status eines Geheimtips (oder sollte ich sagen: eines hässlichen Entleins?). Vielleicht, weil sie einem (System-/DB-Administrator) etwas Vorüberlegung und einmaligen, manuellen Aufwand abverlangen. Die Vorteile sind den Aufwand aber wert!

Eigenschaften von HugePages:

• 2 MB groß, also wird die PageTable um Faktor 500 kleiner.
• Die PageTable wird nicht für jeden Prozess kopiert.
• Dürfen nicht geswappt werden.
• Ihre Anzahl muss als Kernel-Parameter vorab festgelegt werden. Das erfordert also etwas Vorberechnung und i.d.R. einen Neustart des Servers.

Berechnung und Konfiguration

(Getestet mit Oracle 11.2.0.4 unter RHEL 6.5)

Es gibt ein Script von Oracle Support, das bei laufenden Datenbanken die insgesamt benötigten HugePages berechnet (Doc ID 401749.1). Die Berechnung lässt sich aber auch per Faustformel leicht selbst vornehmen.

nr_hugepages = SGA-Größe / 2 MB + 5

Beispiel für 20 GB SGA (Berechnung in MB):

20 * 1024 M => 20480 M

Größe in MB / Hugepagesize:

20480 M / 2 M = 10240

Zur Sicherheit 5 Pages pro Instanz als Reserve hinzufügen ==> 10245

Die 5 HugePages sind eine Reserve für große SGAs, die unter Umständen über mehrere Shared-Memory-Segmente verteilt sind. Hier kann es passieren, das es pro Shared-Memory-Segment zur ‚Verschwendung‘ von kleinen Teilen einer HugePage kommt. Am Ende werden dann ein paar HugePages extra benötigt, die ansonsten fehlen, wenn keine Reserve einkalkuliert wurde.

OS-Einstellungen

Die ermittelte Anzahl Speicherseiten in sysctl.conf eintragen:

$ vi /etc/sysctl.conf

vm.nr_hugepages = 10245

Falls nicht schon gesetzt, die Limits für den RAM-Verbrauch auf knapp unterhalb des verfügbaren RAMs setzen.

Bsp. für 64 GB RAM:

$ vi /etc/security/limits.conf

*   soft   memlock    60397977
*   hard   memlock    60397977

Prinzipiell können die Einstellungen der sysctl.conf im laufenden Betrieb mit

sysctl -p

aktiviert werden. Vorsichtshalber sollte aber der Host neu gestartet werden!

reboot

Oracle-Einstellungen

HugePages können nicht mit AMM (Automatic Memory Management) benutzt werden!

• ==> MEMORY_TARGET und MEMORY_MAX_TARGET nicht setzen bzw. entfernen!

Stattdessen einstellen:

• SGA_TARGET
• SGA_MAX_SIZE

oder auch gezielt Teilbereiche der SGA, wie db_cache_size, shared_pool_size, etc.

• Instanz(en) durchstarten.

Verifizieren, ob HugePages genutzt werden

Nach dem Hochfahren der DB:

grep Huge /proc/meminfo

HugePages_Total:	7686
HugePages_Free:	80
Hugepagesize:	2048 kB

Die Differenz zwischen „Total“ und „Free“ zeigt, dass die HugePages in Verwendung sind. Das Format der Ausgabe kann je nach OS etwas abweichen.

Troubleshooting

• Ab Oracle 11g: USE_LARGE_PAGES=ONLY einstellen und durchstarten. Die Instanz fährt dann nicht hoch, wenn nicht genug HugePages verfügbar sind.
• Oracle >= 11.2.0.3 kann auch eine Mischung aus HugePages und Standard Pages benutzen!

Die Vorteile zusammengefasst

Huge Pages

• sparen RAM, da für ihre Verwaltung 500x(Anzahl Prozesse) weniger RAM aufgewendet werden muss.
• werden nicht geswappt –> keine Performance-Verluste durch Swapping der SGA.
• entlasten die CPU durch
  • weniger TLB Misses
  • viel geringeren Aufwand für die Verwaltung der Page Table.

Weblinks

Auf Deutsch

• Gunther Pipperr: Huge Pages für eine Oracle Datenbank einrichten – Transparent Huge Pages deaktivieren
• DBA Blog: Verwendung von HugePages für Oracle

Auf Englisch

• Oracle 11.2 Doku: Very Large Memory and HugePages
• Oracle Linux 6 Administrator’s Solution Guide: Configuring HugePages for Oracle Database
• MOS ID 361323.1 – HugePages on Linux: What It Is… and What It Is Not…
• MOS ID 1392497.1 – USE_LARGE_PAGES To Enable HugePages In 11.2

• Pythian Goodies: The Answer to Free Memory, Swap, Oracle, and Everything
• SAP Community: Myths and common misconceptions about (transparent) huge pages for Oracle databases (on Linux) uncovered
• Redhat Linux 6 Documentation – Huge Pages and Transparent Huge Pages

• Ronny Egners Blog: MEMORY_TARGET (SGA_TARGET) or HugePages – which to choose?
• http://dbasolutions.wikispaces.com/SHMMAX+and+SHMALL
• http://blog.enkitec.com/2012/07/hugepages-configuration-and-monitoring/
• http://oracle-base.com/articles/linux/configuring-huge-pages-for-oracle-on-linux-64.php#disabling-transparent-hugepages
• https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt
• Wikipedia: TLB
• LWN.net: Huge pages part 5: A deeper look at TLBs and costs