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
sehr schöne Beschreibung, danke!
Gefällt mirGefällt 1 Person
Danke, sehr interessant.
Nur eine Anmerkung:
allokieren oder allozieren?
Von lateinischen Verben auf -care oder -cere — sofern dieser Endung ein Vokal vorausgeht — abstammende deutsche Verben enden auf -zieren, nicht -kieren, z. B. identifizieren, kommunizieren, modifizieren, multiplizieren, produzieren, sezieren, verifizieren. Ausnahmen: karikieren, defäkieren (neben defäzieren).
Folglich lauten die von locare abgeleiteten Formen: lozieren, allozieren, dislozieren, translozieren, relozieren (allesamt im achtbändigen Duden oder im großen Fremdwörterduden verzeichnet). allozieren hat dabei die Bedeutung [Mittel] zuweisen, bereitstellen und entspricht dem englischen allocate.
allokieren hingegen heißt jemanden anreden, von lat. alloqui anreden, trösten, eine Ansprache halten; siehe auch Allokution Ansprache (des Papstes).
Gefällt mirGefällt mir
Hallo Herr Haase,
das war aber ein ausführlich begründeter Hinweis auf einen Schreibfehler! In der Tat habe ich mich da zu einem Anglismus hinreißen lassen. De facto sind offenbar beide Schreibweisen gebräuchlich, im Duden dokumentiert und gerne Gegenstand der Sprachdebatte, wie z.B. auch beim Wiktionary. Als ehemaliger Lateinschüler werde ich aber künftig „allozieren“ bevorzugen.
Gefällt mirGefällt mir
Hallo Uwe,
dann liegt es bei mir auch daran, dass ich mal Latein gelernt habe, sonst wäre es mir vllt. gar nicht aufgefallen ;)
Gefällt mirGefällt mir
Pingback: Windows Large Pages | Oraculix
Pingback: Yet another post about huge pages and Oracle – Justyna Nadriczna
Mittlerweile ist der Artikel schon über vier Jahre alt, und die Linux-Welt hat sich etwas weiter gedreht. Daher ein kleines Update zur Vorgehensweise für neuere Kernels (z.B. UEK4 bei OL / RHEL 7):
VOR dem „sysctl -p“ sollten Caches geleert werden:
echo 2 > /proc/sys/vm/drop_caches
Das haben frühere Kernels implizit gemacht, nun aber aus Stabilitätsgründen nicht mehr. So kann es nun passieren, dass nicht mehr genug freies RAM verfügbar ist, um die Hugepages zu allozieren.
Ein Reboot sollte erst versucht werden, wenn alles korrekt eingerichtet und Oracle erfolgreich gestartet werden konnte. Andernfalls könnte eine unentdeckte, fehlerhafte Konfiguration zu massiven Startproblemen führen.
Gefällt mirGefällt mir