Vm.overcommit_memory=2 is the right setting for servers • Hacker News Board

Re: Vm.overcommit_memory=2 is the right setting for servers

#71

Post by Spivak » Sat, Dec 20, 2025, 2:16 AM UTC

loeg wrote: post #60

blibble wrote: post #46

Earlier quoted context omitted.

did you read it the article? there's a large section on redis the author says it's bad design, but has entirely missed WHY it wants overcommit

You haven't made a connection, though. What does fork have to do with overcommit? You didn't connect the dots.

If you turn overcommit off then when you fork you double the memory usage. The pages are CoW but for accounting purposes it counts as double because writes could require allocating memory and that's not allowed to fail since it's not a malloc. So the kernel has to count it as reserved.

Re: Vm.overcommit_memory=2 is the right setting for servers

#72

Post by nextaccountic » Sat, Dec 20, 2025, 2:21 AM UTC

sidewndr46 wrote: post #58

LordGrey wrote: post #53

Earlier quoted context omitted.

malloc() and friends may always return NULL. From the man page: If successful, calloc(), malloc(), realloc(), reallocf(), valloc(), and aligned_alloc() functions return a pointer to allocated memory. If there is an error, they return a NULL pointer and set errno to ENOMEM. In practice, I find a lot of code that does not check for NULL, which is rather distressing.

It's been a while but while I agree the man page says that, my limited understanding was the typical libc on linux won't really return NULL under any sane scenario. Even when the memory can't be backed

Even with overcommit enabled, malloc may fail if there is no contiguous address space available. Not a problem in 64 bits but may occasionally happen in 32 bits

Re: Vm.overcommit_memory=2 is the right setting for servers

#73

Post by PunchyHamster » Sat, Dec 20, 2025, 2:35 AM UTC

Sure if you don't like your stuff to work well. 0 is default for a reason, and "my specific workload is buggy with 0" is not a problem with it, just the reason there are other options

Advertising for 2 with "but apps should handle it" is utter ignorance, and redis example shows that, the database is using the COW fork feature for basically the reason it exists, as do many, many servers and the warning is pretty much tailored for people thinking they are clever and not understanding memory subsystem

Re: Vm.overcommit_memory=2 is the right setting for servers

#74

Post by PunchyHamster » Sat, Dec 20, 2025, 2:36 AM UTC

kg wrote: post #69

vin10 wrote: post #23

Earlier quoted context omitted.

> he way stuff fails when it runs out of memory is really confusing have you checked what your `vm.overcommit_ratio` is? If its curious what kind of failures you are alluding to.

The main scenario that caused me a lot of grief is temporary RAM usage spikes, like a single process run during a build that uses ~8gb of RAM or more for a mere few seconds and then exits. In some cases the oom killer was reaping the wrong process or the build was just failing cryptically and if I examined stuff like top I wouldn't see any issue, plenty of free RAM. The tooling for examining this historical memory us…

you can get statistics off cgroups to get idea what it was (assuming it's a service and not something user ran), but that requires probing it often enough

Re: Vm.overcommit_memory=2 is the right setting for servers

#75

Post by PunchyHamster » Sat, Dec 20, 2025, 2:40 AM UTC

wmf wrote: post #4

This doesn't address the fact that forking large processes requires either overcommit or a lot of swap. That may be the source of the Redis problem.

Author is just ignorant to the technicals and laser focusing on some particular cases that he thinks are problem but are not.

The redis engineers KNOW fork-to-save will at most result in few tens of MBs of extra memory used in vast majority of cases and benefit of seamless saving. Like, there is a theoretical where it uses double the memory but it would require all the data in database be replaced during short interval snapshot is saved and that's just unrealistic

Re: Vm.overcommit_memory=2 is the right setting for servers

#76

Post by PunchyHamster » Sat, Dec 20, 2025, 2:43 AM UTC

silon42 wrote: post #14

Animats wrote: post #6

Setting 2 is still pretty generous. It means "Kernel does not allow allocations that exceed swap + (RAM × overcommit_ratio / 100)." It's not a "never swap or overcommit" setting. You can still get into thrashing by memory overload. We may be entering an era when everyone in computing has to get serious about resource consumption. NVidia says GPUs are going to get more expensive for the next five years. DRAM prices ar…

For me, on the desktop, thrashing overload is the most common way the Linux system effectively crashes... (I've left it overnight a few times, sometimes it recovered, but not always). I'm not disabling overcommit for now, but maybe I should.

It's not gonna change anything. But you might get interested into software like earlyoom and similar, that basically tried to preempt oomkiller and kill something before it gets to sluggish state

Re: Vm.overcommit_memory=2 is the right setting for servers

#77

Post by userbinator » Sat, Dec 20, 2025, 2:49 AM UTC

jcalvinowens wrote: post #36

loeg wrote: post #29

Earlier quoted context omitted.

Surely the source of the waste here is the userspace program not using the memory it allocated, rather than whether or not the kernel overcommits memory. Attributing this to overcommit behavior is invalid.

Obviously. But all programs do that and have done it forever, it's literally the very reason overcommit exists.

Only the poorly-written ones, which are unfortunately the majority of them.

Re: Vm.overcommit_memory=2 is the right setting for servers

#78

Post by barchar » Sat, Dec 20, 2025, 2:49 AM UTC

renehsz wrote: post #2

Strongly agree with this article. It highlights really well why overcommit is so harmful. Memory overcommit means that once you run out of physical memory, the OOM killer will forcefully terminate your processes with no way to handle the error. This is fundamentally incompatible with the goal of writing robust and stable software which should handle out-of-memory situations gracefully. But it feels like a lost cause…

Even besides the aforementioned fork problems not having overcommit doesn't mean you can handle oom correctly by just handling errors from malloc!

Re: Vm.overcommit_memory=2 is the right setting for servers

#79

Post by zrm » Sat, Dec 20, 2025, 2:51 AM UTC

otabdeveloper4 wrote: post #52

EdiX wrote: post #48

This is completely wrong. First, disabling overcommit is wasteful because of fork and because of the way thread stacks are allocated. Sorry, you don't get exact memory accounting with C, not even Windows will do exact accounting of thread stacks. Secondly, memory is a global resource so you don't get local failures when it's exhausted, whoever allocates first after memory has been exhausted will get an error they mig…

> because of fork and because of the way thread stacks are allocated For modern (post-x86_64) memory allocators a common strategy is to allocate hundreds of gigabytes of virtual memory and let the kernel handle deal with actually swapping in physical memory pages upon use. This way you can partition the virtual memory space into arenas as you like. This works really well.

Which is a major way turning off overcommit can cause problems. The expectation for disabling it is that if you request memory you're going to use it, which is frequently not true. So if you turn it off, your memory requirements go from, say, 64GB to 512GB.

Obviously you don't want to have to octuple your physical memory for pages that will never be used, especially these days, so the typical way around that is to allocate a lot of swap. Then the allocations that aren't actually used can be backed by swap instead of RAM.

Except then you've essentially reimplemented overcommit. Allocations report success because you have plenty of swap but if you try to really use that much the system grinds to a halt.

Re: Vm.overcommit_memory=2 is the right setting for servers

#80

Post by PunchyHamster » Sat, Dec 20, 2025, 2:51 AM UTC

renehsz wrote: post #2

Strongly agree with this article. It highlights really well why overcommit is so harmful. Memory overcommit means that once you run out of physical memory, the OOM killer will forcefully terminate your processes with no way to handle the error. This is fundamentally incompatible with the goal of writing robust and stable software which should handle out-of-memory situations gracefully. But it feels like a lost cause…

It's not harmful. It's necessary for modern systems that are not "an ECU in a car"

> Memory overcommit means that once you run out of physical memory, the OOM killer will forcefully terminate your processes with no way to handle the error. This is fundamentally incompatible with the goal of writing robust and stable software which should handle out-of-memory situations gracefully.

The big software is not written that way. In fact, writing software that way means you will have to sacrifice performance, memory usage, or both because you either * need to allocate exactly what you always need and free it when it gets smaller (if you want to keep memory footprint similar)m and that will add latency * over-allocate, and waste RAM

And you'd end up with MORE memory related issues, not less. Writing app where every allocation can fail is just nightmarish waste of time for 99% of the apps that are not "onboard computer of a space ship/plane"