Linux hängt, wenn nicht genügend Speicherplatz zur Verfügung steht

Ich bekomme ein unerwartetes Verhalten, wenn der Arbeitsspeicher meines Computers nicht ausreicht.

Ich habe einen Intel i7-6700 mit 32 GB RAM und verwende Arch Linux mit dem Kernel Vanilla 4.14.8. Ich habe einen 32-GB-Swap auf einem verschlüsselten LVM-Volume auf der SSD-Festplatte.

Während des normalen Betriebs führe ich einige QEMU / KVM-Gäste zusammen mit anderen Dingen (XFCE, Firefox usw.) aus. Die normale Speicherbelegung beträgt etwa 20-30%, fast ohne Swap.

Wenn ich jedoch etwas speicherintensives laufe (z. B. 7za a -md=29zum Komprimieren einer großen Datei), bleibt das System hängen oder friert ein, wenn die Speichernutzung zu 100% erreicht wird. Die Tastatur und die Maus reagieren nicht mehr vollständig, die Anzeige reagiert nicht mehr, die Festplattenaktivität wird angehalten und alle TCP-Verbindungen zur Maschine hängen in der SYN-Phase ab. Die einzige Möglichkeit, sich von dieser Situation zu erholen, besteht darin, die Maschine aus- und wieder einzuschalten.

In dem Moment kurz vor dem Auflegen kann man sehen, dass praktisch kein Swap-Space verwendet wird. Natürlich ist Swap aktiviert, und ich verwende keine bestimmten sysctl-Einstellungen im Zusammenhang mit dem Speicher (insbesondere hat meine vm.swappiness den Standardwert 60).

Was ich nicht verstehe ist folgendes:

• Warum nutzt der Kernel den Swap-Space nicht?
• Warum tritt der Ooom-Killer nicht ein, wenn der Speicher erschöpft ist?

Ich bin kein Kernel-Experte, aber so wie ich es verstehe, soll das System nicht einfrieren / hängen, wenn der Speicher knapp wird. Was ich erwarten würde, ist folgendes:

• Wenn Swap-Speicher verfügbar ist, sollte kein Prozess abgebrochen werden, bis sowohl der Arbeitsspeicher als auch der Swap verbraucht sind (in meinem Fall 64G).
• Selbst ohne Swap soll der Ooom-Killer töten, 7zawenn der Speicher erschöpft ist
• Jeder Prozess, der versucht, mehr Arbeitsspeicher zuzuordnen, als verfügbar ist, sollte auch ohne das Vorstehende einen Fehler erhalten und ordnungsgemäß ausfallen.

Es gibt also drei unabhängige Mechanismen, die verhindern, dass nicht genügend Speicher zur Verfügung steht. Alle scheinen jedoch zu versagen. Ich weiß, dass es einige subtile Probleme gibt, die ich nicht kenne (z. B. Speicher in Ballons von Gast-VMs, gesperrter Speicher usw.), aber ich kann mir wirklich nichts einfallen lassen, was das Verhalten, das ich sehe, erklären würde.

Kann jemand erklären, was hier los ist und warum? Fehlt mir nur etwas? Kann ich etwas tun, um das Hängen deterministisch zu verhindern?

BEARBEITEN:

Ich habe ein paar Differentialtests durchgeführt und das gefunden:

• Verschlüsselter Swap auf LVM-Volume => Maschine friert ein.
• Verschlüsselter Swap auf Partition => alles in Ordnung (Swap wird wie erwartet verwendet, der Computer friert nicht ein).

Es scheint, dass das Problem irgendwie mit LVM zusammenhängt. Ich habe in beiden Fällen dieselbe physische Partition verwendet, daher ist sie auch nicht auf die Festplatte bezogen. Während der Tests habe ich vm.swappiness auf 60 (Standard) gesetzt.

Nur als Randbemerkung - während eines bestimmten Tests habe ich bemerkt, dass in "top" eine "Kerbe" in der Swap-Bar erschien, kurz bevor die Maschine einfrierte. Der Kernel nutzte also eigentlich Swap, aber er dauerte nur etwa 3 Sekunden.

Das Problem sollte leicht reproduzierbar sein.