Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vm.overcommit_memory=2 is the right setting for servers

ariadne.space

Post reply on HN
Print view View original

21–30 of 150 posts

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

#21

Post by jcalvinowens »

toast0 wrote: post #15
jcalvinowens wrote: post #9

There's a reason nobody does this: RAM is expensive. Disabling overcommit on your typical server workload will waste a great deal of it. TFA completely ignores this. This is one of those classic money vs idealism things. In my experience, the money always wins this particular argument: nobody is going to buy more RAM for you so you can do this.

Even if you disable overcommit, I don't think you will get pages assigned when you allocate. If your allocations don't trigger an allocation failure, you should get the same behavior with respect to disk cache using otherwise unused pages. The difference is that you'll fail allocations, where there's a reasonable interface for errors, rather than failing at demand paging when writing to previously unused pages where…

You're correct it doesn't prefault the mappings, but that's irrelevant: it accounts them as allocated, and a later allocation which goes over the limit will immediately fail.

Remember, the limit is artificial and defined by the user with overcommit=2, by overcommit_ratio and user_reserve_kbytes. Using overcommit=2 necessarily wastes RAM (renders a larger portion of it unusable).

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

#22

Post by vin10 »

For anyone feeling brave enough to disable overcommit after reading this, be mindful that default `vm.overcommit_ratio` is 50% which means that if no swap is available, on a system with 2GB of total RAM, more than 1GB of RAM can't be allocated and requests will fail with preemptive OOMs. (e.g. postgresql servers typically disable overcommit)

- https://github.com/torvalds/linux/blob/master/mm/util.c#L753

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

#23

Post by vin10 »

kg wrote: post #10
c0l0 wrote: post #7

I realize this is mostly tangential to the article, but a word of warning for those who are about to mess with overcommit for the first time: In my experience, the extreme stance of "always do [thing] with overcommit" is just not defensible, because most (yes, also "server") software is just not written under the assumption that being able to deal with allocation failures in a meaningful way is a necessity. At best,…

I run my development VM with overcommit disabled and the way stuff fails when it runs out of memory is really confusing and mysterious sometimes. It's useful for flushing out issues that would otherwise cause system degradation w/overcommit enabled, so I keep it that way, but yeah... doing it in production with a bunch of different applications running is probably asking for trouble.

> 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.

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

#24

Post by hparadiz »

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…

That's a normal failure state that happens occasionally. Out of memory errors come up all the time when writing robust async job queues. There are a lot of other reasons a failure could happen but running out of memory is just one of them. Sure I can force the system to use swap but that would degrade performance for everything else so it's better to let it die and log the result and check your dead letter queue after.

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

#26

Post by loeg »

jcalvinowens wrote: post #9

There's a reason nobody does this: RAM is expensive. Disabling overcommit on your typical server workload will waste a great deal of it. TFA completely ignores this. This is one of those classic money vs idealism things. In my experience, the money always wins this particular argument: nobody is going to buy more RAM for you so you can do this.

How does disabling overcommit waste RAM?

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

#27

Post by loeg »

jcalvinowens wrote: post #21
toast0 wrote: post #15

Earlier quoted context omitted.

Even if you disable overcommit, I don't think you will get pages assigned when you allocate. If your allocations don't trigger an allocation failure, you should get the same behavior with respect to disk cache using otherwise unused pages. The difference is that you'll fail allocations, where there's a reasonable interface for errors, rather than failing at demand paging when writing to previously unused pages where…

You're correct it doesn't prefault the mappings, but that's irrelevant: it accounts them as allocated, and a later allocation which goes over the limit will immediately fail. Remember, the limit is artificial and defined by the user with overcommit=2, by overcommit_ratio and user_reserve_kbytes. Using overcommit=2 necessarily wastes RAM (renders a larger portion of it unusable).

If the overcommit ratio is 1, there is no portion rendered unusable? This seems to contradict your "necessarily" wastes RAM claim?

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

#28

Post by jcalvinowens »

loeg wrote: post #26
jcalvinowens wrote: post #9

There's a reason nobody does this: RAM is expensive. Disabling overcommit on your typical server workload will waste a great deal of it. TFA completely ignores this. This is one of those classic money vs idealism things. In my experience, the money always wins this particular argument: nobody is going to buy more RAM for you so you can do this.

How does disabling overcommit waste RAM?

Because userspace rarely actually faults in all the pages it allocates.

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

#29

Post by loeg »

jcalvinowens wrote: post #28
loeg wrote: post #26

Earlier quoted context omitted.

How does disabling overcommit waste RAM?

Because userspace rarely actually faults in all the pages it allocates.

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.

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

#30

Post by jcalvinowens »

loeg wrote: post #27
jcalvinowens wrote: post #21

Earlier quoted context omitted.

You're correct it doesn't prefault the mappings, but that's irrelevant: it accounts them as allocated, and a later allocation which goes over the limit will immediately fail. Remember, the limit is artificial and defined by the user with overcommit=2, by overcommit_ratio and user_reserve_kbytes. Using overcommit=2 necessarily wastes RAM (renders a larger portion of it unusable).

If the overcommit ratio is 1, there is no portion rendered unusable? This seems to contradict your "necessarily" wastes RAM claim?

Read the comment again, that wasn't the only one I mentioned.
Post reply on HN