Live data from Hacker News

PostgreSQL and the OOM killer: Why we use strict memory overcommit

ubicloud.com

71–80 of 140 posts

Re: PostgreSQL and the OOM killer: Why we use strict memory overcommit

#71
post #62

Earlier quoted context omitted.

There was also a bug in the Linux kernel, or did I miss something?

Yes there was. It's detailed in the article.

But why wouldn't have happened with Rust? Sorry I can't find anything about Rust in the article. Or you mean if the Linux kernel was written in Rust and that stupid bool coercion was not possible?

Re: PostgreSQL and the OOM killer: Why we use strict memory overcommit

#72

Earlier quoted context omitted.

That doesn't really explain why it is a footgun.

The last paragraph: > On the modern desktop, where programmers don't care about failing malloc(), disabling overcommit is shooting yourself in the foot. As you can observe, the memory allocations start failing long before the memory is exhausted.

So it's a footgun because a lot of low quality software?

Re: PostgreSQL and the OOM killer: Why we use strict memory overcommit

#73
post #55

The problem with disabling the memory overcommit is that then the RAM is wasted. That can be worked around with setting up swap but then the disk space is wasted.

People like to reinvent things that they are not aware of. Original BSDs used to use strict swap reservation - every anonymous memory page had to have an associated swap page. You had to have the swap 2x of RAM to allow large processes to fork - otherwise you would get an "out of swap" error. FreeBSD implemented overcommit around 2000, I think version 4.x or 5.x.

Re: PostgreSQL and the OOM killer: Why we use strict memory overcommit

#74
post #72

Earlier quoted context omitted.

The last paragraph: > On the modern desktop, where programmers don't care about failing malloc(), disabling overcommit is shooting yourself in the foot. As you can observe, the memory allocations start failing long before the memory is exhausted.

So it's a footgun because a lot of low quality software?

Is Firefox low quality?

Re: PostgreSQL and the OOM killer: Why we use strict memory overcommit

#76
post #72

Earlier quoted context omitted.

So it's a footgun because a lot of low quality software?

Is Firefox low quality?

Well, if Firefox also works on other OSes, it probably should gracefully handle failing allocations, isn't it?

Re: PostgreSQL and the OOM killer: Why we use strict memory overcommit

#77
post #76

Earlier quoted context omitted.

Is Firefox low quality?

Well, if Firefox also works on other OSes, it probably should gracefully handle failing allocations, isn't it?

No, it doesn't handle failing allocations gracefully - https://unix.stackexchange.com/questions/797841/firefox-died...

Re: PostgreSQL and the OOM killer: Why we use strict memory overcommit

#78

Earlier quoted context omitted.

> Typically, performance drops enough that the user kills the program or reboots before the page file expands to fill the disk. And other threads here suggest there is something that will prompt users to kill programs in states like this. Not in the age of NVMe it doesn't. Swap is fast now. Plus, at least on Linux, you can put zswap in front of the regular swap and introduce an even faster level of memory hierarchy a…

Windows does memory compression too.

It's been a while since I've looked at it, but IIRC it doesn't model the compressed RAM as a special swap tier, which IMHO is a pretty elegant way to look at it.

Re: PostgreSQL and the OOM killer: Why we use strict memory overcommit

#79
post #71

Earlier quoted context omitted.

Yes there was. It's detailed in the article.

But why wouldn't have happened with Rust? Sorry I can't find anything about Rust in the article. Or you mean if the Linux kernel was written in Rust and that stupid bool coercion was not possible?

It's the latter; Rust won't allow the int->bool coercion.

Though to be absolutely pedantic, !x is an int for x:int in C, there is no bool coercion involved; an if-statement takes an expression of any scalar value and evals to true on non-zero. Not that that helps to avoid introducing bugs anyway.

Re: PostgreSQL and the OOM killer: Why we use strict memory overcommit

#80
post #45

Linux vm defaults are legit insane in 2026. - system dies under memory pressure (regardless of swapping, actually not having swap makes it worse which should be common knowledge by now) - system dies under disk pressure even if there are tons of free memory (this one is fun to diagnose) - system can technically not die, but render itself useless (or worse) under memory pressure by the oom killer - memory compression…

Yeah I noticed and was surprised after using ec2 that it didnt really have a sizable swap so it would lock up if I used enough memory importing a db export. Was genuinely surprised.
Post reply on HN