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.
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.
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
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.
Under Windows NT 4.0, Win2k, or WinXP and on, the page file has a built-in size limit that you can set. You can indirectly force that minimum size to increase if you enable full memory dump capture in the event of a crash (it must be larger than main memory to do that) and that was really easy to do so I think a lot of people made that mistake. Even on the modern Windows, if you have a crash then the system will automatically enable full memory dumps for the next 4 weeks hoping to be able to debug the second crash. That can also result in the minimum size increasing beyond the maximum you set, but in neither case does it grow indefinitely.
Eventually the OS will start returning an error that it's out of memory or out of virtual memory. But if the application you're running can handle that gracefully, then it may not even crash.
I think Windows is sluggish now in part because it's about 5 or 6 layers of abstractions piled on top of each other between the application and the hardware, and also because Microsoft keeps jamming services and side projects onto you. It's been a long time since Microsoft has adopted the "shut up and get out of the user's way" approach to OS design. Now it loves to distract you from the program you're working in.
Running out of memory on a linux server sounds more like a skill issue than something comparable to how a desktop OS should behave :\
Thing is that I never know this could happen. As a Windows user I'm used to a system that does stuff in the background without knowing how it works.
My Linux VM's can be broken because I'm in charge and I'm a noob. I kind of love it. I've learned so much from troubleshooting.
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.
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.
So Apple can build a whole user-controlled GUI workflow around memory exceptions, which Linux cannot.
Maybe what needs to happen is new Linux syscalls + signals for DEs to utilise for building memory exception UIs? But the problem then with that is you’re impacting the portability of those DEs. So some maintainers might still refuse to work with Linux to provide this.
That all said, I’m pretty sure KDE does provide GUI tools for when this kind of scenario arises.
Also we cannot use the reasoning Linux means distributions, instead of using GNU/Linux for it, and other times Linux is just the kernel, depending on convenience.
You did. But without examples, it’s a meaningless throwaway.
Personally, I can’t say I’ve pushed many other UNIX desktops that far that they’ve OOMed. Except maybe OpenSolaris and FreeBSD, neither of which faired much better. But they’d also suffer from the same kind of DE development issues I described for Linux.
> Also we cannot use the reasoning Linux means distributions, instead of using GNU/Linux for it, and other times Linux is just the kernel, depending on convenience.
I’m not saying it for convenience. I’m saying it because it matters in this specific situation.
Surely you must understand that the reason Windows and macOS have arguably better GUI support for OOM is because the same company that owns the kernel also writes the frontend too? It’s hardly rocket science as a concept.
As I said in my previous comment, there are ways Linux (the kernel) could work with DEs to bridge that gap. But at present, they’re entirely separate concerns.
In any case, Xenix, DG/UX, SunOS/Solaris, Aix, HP-UX, z/OS UNIX, NeXTSTEP.
The context of the thread is about the UX.
And the OS crashing isn’t a better option than an OOM killer. Frankly, there’s no good automated options. That’s why modern desktop OSs present users with a warning. And hence why we are talking about GUIs.
> In any case, Xenix, DG/UX, SunOS/Solaris, Aix, HP-UX, z/OS UNIX, NeXTSTEP.
Listing OSs doesn’t explain how they handle things better.
For example you’ve cited SunOS and I already said previously, I’ve seen SunOS completely die on its arse when OOM.
Alas, not one that was made back in 1970, so here we are.
To be clear: I’m not trying to defend Linux here. Just calling out the GPs BS when he said Linux is uniquely bad in POSIX.
Linux OOM handling is just atrocious.