Wenn Amazon EMR YARN mehr Speicher gibt, als die Maschine tatsächlich hat

Amazon EMR veröffentlicht yarn.nodemanager.resource.memory-mb für jeden Instance-Typ in seinen Task Configuration Tables. Der NodeManager behandelt diesen Wert als das Speicherbudget für Container.

Bei einigen Instance-Größen ist dieses Budget größer als der RAM, den das Gastbetriebssystem tatsächlich nutzen kann. Ich bin auf dieses Problem erstmals während meiner Zeit bei AWS gestoßen. Die entsprechenden Standardwerte stehen bis heute in diesen öffentlichen Tabellen.

Die Zahlen gehen nicht immer auf

Nehmen wir m5.24xlarge. AWS gibt für diese Instance 384 GiB RAM an. EMR konfiguriert:

yarn.nodemanager.resource.memory-mb = 385024

Damit darf YARN 376 GiB Speicher zuweisen.

Linux sieht jedoch nicht zwangsläufig die vollen 384 GiB. Öffentliche NUMA-Messungen für m5.24xlarge zeigen etwa 191.415 MiB pro NUMA-Node bei zwei Nodes, also insgesamt ungefähr 374 GiB.

Von EC2 angegebener Speicher:  384 GiB
Für Linux nutzbarer Speicher: ~374 GiB
Von YARN konfigurierter Speicher: 376 GiB

YARN kann dadurch mehr Container-Speicher einplanen, als dem Gastbetriebssystem tatsächlich zur Verfügung steht.

Dasselbe Muster zeigt sich bei m5.16xlarge. EMR setzt für YARN 253.952 MiB beziehungsweise 248 GiB. Öffentliche NUMA-Werte liegen dagegen bei ungefähr 246,5 GiB über beide Nodes hinweg.

Diese Differenz ist relevant. Linux MemTotal bezeichnet den nutzbaren RAM nach Reservierungen durch Plattform und Kernel. Das Betriebssystem, der NodeManager, Hadoop-Daemons und weitere Agents benötigen zusätzlich ihren eigenen Anteil des verbleibenden Speichers.

Speicherbuchhaltung ist kein physischer RAM

yarn.nodemanager.resource.memory-mb ist ein Wert für die Ressourcenbuchhaltung. Er sagt YARN, wie viel Speicher es zuweisen darf. Er erzeugt keinen physischen RAM.

Wenn YARN Container bis an dieses Limit verteilt, kann die Maschine unter Speicherdruck geraten, selbst wenn jeder einzelne Spark Executor korrekt in seine konfigurierte Container-Größe passt.

Du kannst Heap, Memory Overhead und die YARN-Container-Berechnung überprüfen, feststellen, dass mathematisch alles passt, und trotzdem an der falschen Stelle suchen. Die Spark-Konfiguration kann intern vollkommen konsistent sein, während die zugrunde liegende Annahme auf Node-Ebene nicht stimmt.

Mehr Nodes hinzuzufügen kann das Symptom verdecken. Die Ursache erklärt es nicht.

Die EMR-Standardwerte überschreiben

EMR erzwingt diese Werte nicht. yarn.nodemanager.resource.memory-mb gehört zur yarn-site-Klassifizierung und die Anwendungskonfiguration kann überschrieben werden. Bei einheitlichen Instance Groups können über Configurations innerhalb von InstanceGroupConfig unterschiedliche Konfigurationen pro Gruppe gesetzt werden.

{
  "Classification": "yarn-site",
  "Properties": {
    "yarn.nodemanager.resource.memory-mb": "YOUR_SAFE_VALUE"
  }
}

Einfach ein paar Gigabyte abzuziehen und das Problem damit als gelöst zu betrachten, ist keine gute Strategie. Der richtige Wert hängt vom Instance-Typ, der EMR-Version, den auf dem Cluster installierten Komponenten und den weiteren Prozessen auf dem Worker ab.

YARN-Speicher als Teil der Anwendung betrachten

Spark-Konfiguration, YARN-Ressourcenbuchhaltung, Linux-Speicher und der verwendete EC2-Instance-Typ müssen gemeinsam betrachtet werden. Meistens besteht die Lösung nicht darin, ein weiteres Dutzend Nodes hinzuzufügen. Oft ist es ein gezielter YARN-Override, der zu dem Speicher passt, den das Gastbetriebssystem tatsächlich nutzen kann.

Der Fehler kann in Spark sichtbar werden, während die eigentliche Ursache mehrere Ebenen tiefer liegt. Wenn ein Team ausschließlich von der Anwendungsebene nach unten debuggt, kann die Suche Tage dauern. Für jemanden, der Spark, YARN und EMR bereits sehr gut kennt, lässt sich ein solcher Unterschied häufig innerhalb weniger Stunden identifizieren.

Brauchst du Unterstützung?

Wenn EMR-Jobs auf eine Weise fehlschlagen, die sich allein anhand der Spark-Konfiguration nicht erklären lässt, kann ich helfen. Während meiner Zeit bei AWS habe ich viel Zeit mit tiefgehenden Analysen von Spark und EMR verbracht. Manchmal besteht die richtige Lösung nicht darin, mehr Compute hinzuzufügen, sondern herauszufinden, warum die bereits bezahlte Rechenleistung sich nicht so verhält, wie sie sollte.

Die Ideen und inhaltlichen Aussagen dieses Artikels stammen von mir. KI hat mich beim Korrekturlesen und bei der Formatierung unterstützt. Die technischen Angaben waren zum Zeitpunkt der Veröffentlichung korrekt.

Hinweis: Dieser Artikel wurde mithilfe von KI aus dem englischen Original ins Deutsche übersetzt.