Was ist der Hintergrund dafür, dass `ulimit -m` / RLIMIT_RSS nicht funktioniert?

Question

Gemäß man setrlimit(worauf man ulimitich hinauswill),

RLIMIT_RSS

Gibt die Grenze (in Bytes) des Resident-Sets des Prozesses an (die Anzahl der virtuellen Seiten, die im RAM resident sind). Diese Grenze hat nur unter Linux 2.4.x, x < 30, Auswirkungen und betrifft dort nur Aufrufe von madvise(2), die MADV_WILLNEED angeben.

Es scheint also, dass ulimit(und setrlimit) nur den von einem Prozess verwendeten virtuellen Speicher einschränken können. Auf der anderen Seite können Antworten wieDieses hierbehaupten (offenbar zu Recht), dass der virtuelle Speicher eine nahezu bedeutungslose Statistik ist, insbesondere beispielsweise bei Java-Anwendungen, bei denen typischerweise weit mehr virtueller Speicher angefordert wird, als verwendet wird.

Ich frage mich also, wie es zu dieser scheinbaren Diskrepanz zwischen den Grenzen, die ich dem System auferlegen kann, und den Zahlen, die tatsächlich von Bedeutung sind, gekommen ist. Soweit diese Frage beantwortet werden kann, stellt sich die Frage, warum dies der gegenwärtige Stand der Dinge ist.

Answer 1

RSS ist ein Implementierungsdetail. Die einzigen Ressourcen, die Ihr Programm steuern kann, sind RLIMIT_AS und RLIMIT_DATA. Eine Unix-Implementierung könnte RSS == VMA immer beheben (den gesamten angeforderten Speicher festschreiben) und alle Java-Virtual-Machines würden beim Laden abstürzen, wenn der Computer nicht leistungsstark genug ist, um auf die Verschwendung seines Speichers vorbereitet zu sein.

Daher stellen die Kommentare im referenzierten Thread lediglich die Meinung dieser Person dar und stimmen nicht mit der Architektur von Unix überein.

So probieren Sie dieses Verhalten unter Linux aus:

1. Booten Sie den Kernel mit dem Parameter „mem=4G“ (oder versuchen Sie es mit anderen Werten).
2. sudo sysctl vm.overcommit_memory=2
3. Führen Sie Chromium oder ein anderes Programm aus, das versucht, mehr als 4 GB zu reservieren (Absturz).