CPU-Platzierung und Speicherregeln passen nicht zusammen · Linux Fix Lab

Symptome und Geltungsbereich

Eine speicherintensive Last schwankt nach CPU-Pinning im Durchsatz.
Eine systemd-Unit mit NUMAPolicy endet mit NUMA_POLICY.

Betroffene Umgebung

Linux-Hosts oder Gäste mit mehreren NUMA-Nodes; ein Einzel-Node-System gewinnt keine Remote-Speicheroptimierung.

Erkennbare Meldungen (synthetische Beispiele)

systemd[1]: example.service: Main process exited, code=exited, status=242/NUMA_POLICY

Dies ist ein Startregelfehler, kein Beweis für Remote-Speicher als Ursache laufender Latenz.

Mögliche Ursachen

Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.

CPU-Affinität und Speicherplatzierung können nach Migration oder First-Touch unterschiedliche Nodes betreffen.
Eine Regelmaske kann nicht verfügbare Nodes nennen oder mit erlaubten cpuset-Speicher-Nodes kollidieren.

Sicher prüfen

Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.

Prüfschritt 1

Liest NUMA-Topologie mit vorhandenem numactl.

numactl --hardware

Ergebnis einordnen: Vergleiche Node-CPUs, freien Speicher und Distanzmatrix. Ein einzelner Node schließt diese Remote-Lokalitätsannahme aus.

Prüfschritt 2

Ersetze 1234 durch den Last-PID; proc-Zugriff kann Eigentümer- oder berechtigte Administratorrechte erfordern.

cat /proc/1234/numa_maps

Ergebnis einordnen: N0-/N1-Zahlen zeigen aktuelle Seitenorte, Regelbezeichnungen das gewünschte Verhalten. Gemeinsame Mappings und Migration machen einen Einzelwert nicht zur Latenzmessung.

Prüfschritt 3

Ersetze die betroffene Unit; liest Regeln ohne Affinitätsänderung.

systemctl show example.service -p NUMAPolicy -p NUMAMask -p CPUAffinity -p AllowedMemoryNodes

Ergebnis einordnen: Vergleiche Speichermaske mit vorhandenen und erlaubten Nodes. CPUAffinity macht bereits belegten Speicher nicht automatisch lokal.

Nächste Schritte nach Befund

Platzierung an gemessene Lokalität anpassen

Wenn Topologie und Seitenorte ein Lokalitätsproblem stützen, erprobe CPU- und Speicherplatzierung gemeinsam über eine unterstützte Startregel. Initialisiere die Last kontrolliert neu für passende First-Touch-Platzierung.

Vorsicht: Feste Bindung kann trotz freiem Speicher anderer Nodes Allokationen verhindern. CPU-Affinität migriert nicht automatisch jede vorhandene Seite.

Wiederherstellung / Rücknahme: Stelle Startregel und Affinität zurück und starte die Last mit vorheriger Platzierung.

Hat dir dieser Hinweis geholfen?

Hinweis teilen #

Ungültige oder zu strenge Node-Maske korrigieren

Wenn die Maske ungültig oder durch cpuset ausgeschlossen ist, wähle gültige erlaubte Nodes oder die dokumentierte Standard-/Preferred-Regel. Nutze Interleave nur bei begründetem gemessenem Bandbreitengewinn.

Vorsicht: Regeln besitzen unterschiedliche Allokations-Rückfälle. Prüfe installierte systemd- und Kernel-Unterstützung vor dem Beibehalten.

Wiederherstellung / Rücknahme: Stelle NUMAPolicy, NUMAMask und cpuset-Werte zurück und prüfe Topologie sowie Anwendungsstart.