Linux Huge Pages: Schnellstart

7 Antworten

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

Auf Englisch

7 Gedanken zu „Linux Huge Pages: Schnellstart“

  2. Gerrit Haase

    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 mir

    Antwort ↓
    1. Uwe M. Küchler Autor

      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 mir

      Antwort ↓
      1. Gerrit Haase

        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 mir

  3. Pingback: Windows Large Pages | Oraculix

  4. Pingback: Yet another post about huge pages and Oracle – Justyna Nadriczna

  5. Uwe M. Küchler Autor

    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 mir

    Antwort ↓

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

Gravatar
WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. ( Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. ( Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. ( Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. ( Abmelden /  Ändern )

Abbrechen

Verbinde mit %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.