Hacker News: man8alexd

New comment by man8alexd in "Ask HN: Who wants to be hired? (August 2026)"

man8alexd — Wed, 05 Aug 2026 13:03:51 +0000

Location: Belgrade, Serbia (UTC+2)

Remote: yes (working exclusively remotely for the past 20 years)

Willing to relocate: yes

Technologies: AWS, Kubernetes, Nomad, Docker, podman, HashiCorp Consul, Vault, Packer, Terraform, Ansible, Chef, Puppet, Grafana, Loki, Prometheus, ELK stack, Jenkins, GitHub Actions, Flux, GitLab, Postfix, HAProxy, MySQL, MariaDB, PostgreSQL, Ruby, Python, bash, C

Résumé/CV: https://alexeydemidov.com/cv

Email: in the resume

GitHub: https://github.com/AlexeyDemidov

LinkedIn: https://www.linkedin.com/in/alekseydemidov/

ServerFault: https://serverfault.com/users/23022/alexd

Have been playing with Linux and FreeBSD for over two decades. Run an ISP engineering team for a decade, now building and maintaining cloud infras.

New comment by man8alexd in "PostgreSQL and the OOM killer: Why we use strict memory overcommit"

man8alexd — Mon, 06 Jul 2026 16:36:21 +0000

Why do you think it is a better default? What does it solve?

New comment by man8alexd in "PostgreSQL and the OOM killer: Why we use strict memory overcommit"

man8alexd — Mon, 06 Jul 2026 06:00:28 +0000

You have a lot of unused anonymous memory that is better swapped out and used as a file cache. Specifically for Linux swap, see https://chrisdown.name/2018/01/02/in-defence-of-swap.html

New comment by man8alexd in "PostgreSQL and the OOM killer: Why we use strict memory overcommit"

man8alexd — Sun, 05 Jul 2026 20:28:28 +0000

You can't fix the fact that you can't predict the future. The software will always allocate more memory than it needs because it can't predict its future resource usage, so limiting memory allocation with strict overcommit is meaningless.

New comment by man8alexd in "PostgreSQL and the OOM killer: Why we use strict memory overcommit"

man8alexd — Sun, 05 Jul 2026 15:29:55 +0000

About shared memory included in the memory size calculations https://lkml.iu.edu/1902.2/05674.html

New comment by man8alexd in "FreeBSD ate my RAM"

man8alexd — Sun, 05 Jul 2026 15:21:04 +0000

The kernel keeps track of active/inactive pages by scanning page tables during the reclaim process. It only scans until it finds enough inactive pages to reclaim. Scanning all pages all the time is very expensive from a performance point of view.

New comment by man8alexd in "PostgreSQL and the OOM killer: Why we use strict memory overcommit"

man8alexd — Sat, 04 Jul 2026 21:07:09 +0000

You can't know when the OOM killer is awake and hunting. The kernel doesn't know that.

New comment by man8alexd in "PostgreSQL and the OOM killer: Why we use strict memory overcommit"

man8alexd — Sat, 04 Jul 2026 09:01:16 +0000

OOM is better. If a program doesn't handle ENOMEM properly, then its state is unpredictable and can lead to data corruption.

New comment by man8alexd in "FreeBSD ate my RAM"

man8alexd — Sat, 04 Jul 2026 08:54:44 +0000

Linux MemAvailable from /proc/meminfo is just an estimation calculated as an arbitrary percentage (50%) of free and potentially reclaimable memory.

You can't determine how much of the memory can actually be reclaimed under memory pressure until you try to reclaim it.

New comment by man8alexd in "PostgreSQL and the OOM killer: Why we use strict memory overcommit"

man8alexd — Sat, 04 Jul 2026 08:42:36 +0000

There is no point in managing memory allocations as they have little relation to actual memory usage. There are also other methods than the OOM killer to handle OOM, like process throttling using cgroups "memory.high" limits.

New comment by man8alexd in "PostgreSQL and the OOM killer: Why we use strict memory overcommit"

man8alexd — Sat, 04 Jul 2026 08:34:38 +0000

In this specific case, the correct behaviour would be to drop a part of the buffer pool until the memory pressure is gone. The context-dependent question is how much and how fast to drop. The current implementation drops to a single configurable level but I suspect it could have implemented better heuristics.

New comment by man8alexd in "PostgreSQL and the OOM killer: Why we use strict memory overcommit"

man8alexd — Sat, 04 Jul 2026 08:09:15 +0000

Because no one can predict the future, and they don't know how many resources they will need.

New comment by man8alexd in "PostgreSQL and the OOM killer: Why we use strict memory overcommit"

man8alexd — Sat, 04 Jul 2026 08:03:51 +0000

Maybe you should skip running a useless child process and just use PSI to monitor memory pressure.

New comment by man8alexd in "PostgreSQL and the OOM killer: Why we use strict memory overcommit"

man8alexd — Fri, 03 Jul 2026 23:19:34 +0000

You can always tell the system not to kill your Photoshop (or whatever else) by setting the OOM Score Adjust. This mechanism has existed for almost two decades and systemd has supported it for over a decade.

New comment by man8alexd in "FreeBSD ate my RAM"

man8alexd — Fri, 03 Jul 2026 23:16:33 +0000

You will be surprised by how inaccurate memory measurements are.

New comment by man8alexd in "FreeBSD ate my RAM"

man8alexd — Fri, 03 Jul 2026 22:39:57 +0000

See this retrocomputing.SE question https://retrocomputing.stackexchange.com/questions/32492/ori...

New comment by man8alexd in "FreeBSD ate my RAM"

man8alexd — Fri, 03 Jul 2026 22:21:59 +0000

FreeBSD didn’t have memory overcommit and instead used strict swap reservation - each allocated anonymous memory page was supposed to have a corresponding swap page. This required 2x RAM swap space, otherwise you would get “out of swap” when forking a large process. FreeBSD implemented memory overcommit around 2000.

New comment by man8alexd in "PostgreSQL and the OOM killer: Why we use strict memory overcommit"

man8alexd — Fri, 03 Jul 2026 21:54:04 +0000

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

New comment by man8alexd in "PostgreSQL and the OOM killer: Why we use strict memory overcommit"

man8alexd — Fri, 03 Jul 2026 21:10:39 +0000

Is Firefox low quality?

New comment by man8alexd in "PostgreSQL and the OOM killer: Why we use strict memory overcommit"

man8alexd — Fri, 03 Jul 2026 21:08:58 +0000

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.