Vielleicht habt ihr mal ein Redis gestartet und eine Meldung bekommen, dass Ihr doch mal im Kernel overcommitment umstellen sollt.
Overcommitment ist im Prinzip, dass der Kernel bei malloc niemals null zurück gibt, wenn das System gar keinen Speicher mehr hat. Das hört sich ziemlich falsch an und uns allen wurde ja immer beigebracht, dass wir das Ergebnis von malloc immer checken sollten. In der Praxis haben das genug Leute nicht getan, sodass man sich Overcommitment ausgedacht hat. Dabei wird der Anwendung immer ein Pointer gegeben. Erst, wenn die Anwendung schreibend darauf zugreift, wird die eigentliche Allokation durchgeführt. So kann man verhindern, dass eine Anwendung beendet wird, wenn sie zu viel Speicher anfordert und den gar nicht benutzt.
Das ist einer der Gründe, warum Allokationen in Rust nicht irgendwie ein Result zurückgeben. Man hat einfach Overvommitment als Default angenommen und denkt sich “wenns nicht klappt, panict die Anwwendung halt und da die meisten overcomitten, brauchen wir den Entwickler gar nicht zum Handlen des OOM-Falls zwingen”. In Zig ist das nicht so. Für mich ist die Designentscheidung bei Rust ein Zeichen dafür, dass es für Userspace-Anwendungen designt wurde. Wenn man im Kernel kmalloc macht, wird (meines wissens nach) nicht overcommited. Somit hat man da bei Rust ein Problem, das man im Nachhinein irgendwie noch fixen musste. Das haben sie glaub ich geschafft.
Redis will deshalb, dass es nicht vom OS angelogen wird, wenn es malloc macht, um bessere Fehlerbehandlung zu machen.
Jedenfalls ist hier ein Artikel darüber: vm.overcommit_memory=2 is always the right setting for servers.