Comment by mtgh2s
1 day ago
From my experience, Windows does freeze and become completely unusable too, just not usually from RAM usage hitting 100%.
I don't use Windows much, nor do I care much about that environment, but from what I've seen it seems to keep RAM usage below 100% most of the time. What I do see pretty often is the drive getting stuck at 100% usage instead, which makes the whole system ridiculously unusable anyway.
Windows does freeze and become unstable, but it's usually because of some ring 0 errors not getting trapped appropriately.
But Windows has always handled both OOM and out of disk space very well. The system will be extremely sluggish, but it typically continues operating.
The Linux design is to keep using memory, then push to swap, and then when you OOM you hard lock. The built in kernel OOM module can miss when RAM usage spikes rapidly. You can enable OOM monitors like systemd-oomd or earlyoom, but they do not run by default, and their behavior is to term the offending process.
The thing about Windows is that when you request memory, you're only granted memory if it can be guaranteed in the first place. The application will get a "not enough memory" error. On Linux, you're permitted to request more memory than the system actually has, with the idea that you won't actually use that much memory. It's optimistic that way. But if you do use it, then you're screwed.
Doesn't Windows, like macOS, automatically expand swap? You can't run out of memory nearly as quickly as you can on Linux. And at least on Windows I always figured this is why it felt so sluggish under load--it ends up paging alot. Not sure why macOS has always felt more consistent; perhaps the OS and major apps are less gratuitous memory hogs?
If you're referring to Apple Silicon, my intuition is that the SoC design allows for higher bandwidth between SSD and RAM which reduces the performance impact of paging. I might be totally wrong though
Linux can be configured to disable memory overcommit
sysctl -w vm.overcommit_memory=2 sysctl -w vm.overcommit_ratio=50
It is probably a bad idea to do that though as it will limit the amount of virtual address space an application can use
Note that the fork()/execve() semantics of Linux pretty much depend on memory overcommit. You may get weird OOM crashes when there is seemingly no memory pressure, if you turn overcommit off.
In the short time between fork() and execve(), the new process duplicates the entire virtual memory of the old one. None of this is physically allocated due to copy-on-write, but still all counts as virtual memory.
1 reply →
Haven't had Windows freeze on me for ages. I had a frozen linux server that ran out of RAM yesterday.
> I had a frozen linux server that ran out of RAM yesterday
This has so many variables that it's practically useless as a data point. We have a few Ubuntu VMs running complex business web applications and their Postgres database on only 4 GB or RAM and 20-50 GB of storage, no swap space. Ocassional high load, but Zero OOM problems for many years.
We could upgrade the RAM, but we were stingy when we created them, and it has worked well so far, so why waste resources? Incidentally, using no swap was a deliberate choice, as it would slow things down too much. We preferred to see and correct any memory/OOM issues beforehand, but fortunately we had none.
True. It's just a tiny Lenovo that I've repurposed as a homelab and that is punching above it's weight with to many applications I suppose. Either way the logs point to RAM issues but it could be my incompetence.
Use a windows server then :D
edit: I meant that regularly hitting OOM on a production server is usually more of a provisioning/resource-management issue. Obviously, how the OS handles OOM once it happens is still its responsibility.
Running out of memory on a linux server sounds more like a skill issue than something comparable to how a desktop OS should behave :\
Windows uses eager memory allocation, and applications will die when they allocate (and think image editor loads a beefy image) or fail to start when it runs out of memory.
Linux uses lazy allocation and overcommits, so what dies isn’t necessarily what you would expect thanks to the OOM killer.
With a fixed swap size windows doesn’t necessarily slow down as it runs out of memory.
YMMV if you don’t have 64 gigs of RAM and a 64 gig swap.
The difference is Linux has fork, while Windows doesn’t, so Linux cannot do accurate accounting (without wasting a lot of memory) while Windows can.
macOS is a UNIX as well, and it isn't the only UNIX that manages to do accounting properly.
5 replies →
This is the best explanation, thanks.
Windows will aggressively page out as you approach RAM usage, MacOS does the same but based on activity iirc. On Linux if you just set up paging (forgot how i did this on arch) you won't have any issues.
I have never had Windows fail so catastrophically as Linux does on OOM or disk exhaustion. Many distros probably still fail to boot with a full disk.
Linux OOM handling is just atrocious.