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

131–140 of 150 posts

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

#131

Post by [deleted] »

dbdr wrote: post #20
LordGrey wrote: post #3

For anyone not familiar with the meaning of '2' in this context: The Linux kernel supports the following overcommit handling modes 0 - Heuristic overcommit handling. Obvious overcommits of address space are refused. Used for a typical system. It ensures a seriously wild allocation fails while allowing overcommit to reduce swap usage. root is allowed to allocate slightly more memory in this mode. This is the default.…

> exceed swap + a configurable amount (default is 50%) of physical RAM Naive question: why is this default 50%, and more generally why is this not the entire RAM, what happens to the rest?

[deleted]

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

#132

Post by kentonv »

coryrc wrote: post #128
kentonv wrote: post #95

When your system is out of memory, you do not want to return an error to the next process that allocates memory. That might be an important process, it might have nothing to do with the reason the system is out of memory, and it might not be able to gracefully handle allocation failure (realistically, most programs can't). Instead, you want to kill the process that's hogging all the memory. The OOM killer heuristic i…

OOM killer often doesn't run soon enough for me; I've even left the machine for twenty minutes and it's still swapping hard. And I do say "often" because it does sometimes work. I have set all my Firefox processes near-maximum priority to kill for the OOM killer, but it didn't help. Also don't forget about memory compression: only meaningful with overcommit.

They say swap is highly highly recommended even if you have plenty of memory.

I don't care, I disable it anyway. Have been doing so for decades. Never caused a problem.

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

#133

Post by immibis »

coryrc wrote: post #128
kentonv wrote: post #95

When your system is out of memory, you do not want to return an error to the next process that allocates memory. That might be an important process, it might have nothing to do with the reason the system is out of memory, and it might not be able to gracefully handle allocation failure (realistically, most programs can't). Instead, you want to kill the process that's hogging all the memory. The OOM killer heuristic i…

OOM killer often doesn't run soon enough for me; I've even left the machine for twenty minutes and it's still swapping hard. And I do say "often" because it does sometimes work. I have set all my Firefox processes near-maximum priority to kill for the OOM killer, but it didn't help. Also don't forget about memory compression: only meaningful with overcommit.

Run without swap or with very little swap. I'm serious. Your modern server has enough memory, way more than 4MB, and you care about consistent latency don't you? Also, swap is wearing our your SSD.

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

#134

Post by ece »

pizlonator wrote: post #33

This is such an old debate. The real answer, as with all such things, is "it depends". Two reasons why overcommit is a good idea: - It lets you reserve memory and use the dirtying of that memory to be the thing that commits it. Some algorithms and data structures rely on this strongly (i.e. you would have to use a significantly different algorithm, which is demonstrably slower or more memory intensive, if you couldn'…

Debugging what causes an OOM situation seems to be a wash with or without overcommit as an end user, I am guessing more warnings/hints would be appreciated by users and developers.

I use zram exclusively as swap, and while doing memory intensive tasks in the background, it's usually something interactive like the browser that ends up being killed. I would turn on swap that's isn't zram if this happened more often. I might also turn off overcommit if apps handled OOM situations gracefully, but as you say, the complexity might not be worth it.

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

#135

Post by saghm »

agilob wrote: post #110

An aircraft company discovered that it was cheaper to fly its planes with less fuel on board. The planes would be lighter and use less fuel and money was saved. On rare occasions however the amount of fuel was insufficient, and the plane would crash. This problem was solved by the engineers of the company by the development of a special OOF (out-of-fuel) mechanism. In emergency cases a passenger was selected and thro…

I get that this is humorous, but it seems like it illustrates the point of why this strategy is useful in the first place: memory is not human life, does not feel pain, and can even be resurrected from swap (which might still take some extra time but still is way less of an issue than the corresponding problem for humans)? If the strongest objection to the system is that it can't be ethically generalized to apply to managing people instead of memory, I think I'm happy with it. I don't care about whether it's inelegant if it works well enough for me in practice when the "victims" are arbitrary values in memory.

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

#136

Post by rnrn »

saghm wrote: post #135
agilob wrote: post #110

An aircraft company discovered that it was cheaper to fly its planes with less fuel on board. The planes would be lighter and use less fuel and money was saved. On rare occasions however the amount of fuel was insufficient, and the plane would crash. This problem was solved by the engineers of the company by the development of a special OOF (out-of-fuel) mechanism. In emergency cases a passenger was selected and thro…

I get that this is humorous, but it seems like it illustrates the point of why this strategy is useful in the first place: memory is not human life, does not feel pain, and can even be resurrected from swap (which might still take some extra time but still is way less of an issue than the corresponding problem for humans)? If the strongest objection to the system is that it can't be ethically generalized to apply to…

This is not about reclaiming memory by swapping the contents out to disk. It is about killing processes due to having overcommitted beyond the available memory plus swap space. The processes thrown out of the plane (targeted by the OOM killer) cannot be resurrected

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

#138

Post by garaetjjte »

immibis wrote: post #133
coryrc wrote: post #128

Earlier quoted context omitted.

OOM killer often doesn't run soon enough for me; I've even left the machine for twenty minutes and it's still swapping hard. And I do say "often" because it does sometimes work. I have set all my Firefox processes near-maximum priority to kill for the OOM killer, but it didn't help. Also don't forget about memory compression: only meaningful with overcommit.

Run without swap or with very little swap. I'm serious. Your modern server has enough memory, way more than 4MB, and you care about consistent latency don't you? Also, swap is wearing our your SSD.

It will happen even without swap. Code pages will get evicted and everything will slow down to a crawl. I have magic SysRq enabled so I can invoke OOM killer from keyboard if that happens.

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

#139

Post by throw0101c »

LordGrey wrote: post #3

For anyone not familiar with the meaning of '2' in this context: The Linux kernel supports the following overcommit handling modes 0 - Heuristic overcommit handling. Obvious overcommits of address space are refused. Used for a typical system. It ensures a seriously wild allocation fails while allowing overcommit to reduce swap usage. root is allowed to allocate slightly more memory in this mode. This is the default.…

> For anyone not familiar with the meaning of '2' in this context:

Source:

* https://www.kernel.org/doc/Documentation/vm/overcommit-accou...

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

#140

Post by throw0101c »

vin10 wrote: post #42
dbdr wrote: post #20

Earlier quoted context omitted.

> exceed swap + a configurable amount (default is 50%) of physical RAM Naive question: why is this default 50%, and more generally why is this not the entire RAM, what happens to the rest?

it's a (then-)safe default from the age when having 1GB of RAM and 2GB of swap was the norm: https://linux-kernel.vger.kernel.narkive.com/U64kKQbW/should...

Probably a safe default as there's extra memory of kernel structures, file buffering, SSH sessions to allow logins to debug why your server suddenly has high load and high IOwait (swapping).

If you know a a system is going to run (e.g.) a Postgres database, then tweaking the vm.* sysctl values is part of the tuning process.

Post reply on HN