5 ms·

I have disabled overcommit both on Windows and on Linux. I hate having random programs being killed. Unfortunately, many programs commit 2x memory than they ac

I have disabled overcommit both on Windows and on Linux. I hate having random programs being killed. Unfortunately, many programs commit 2x memory than they actually use. Often I see ~32GB committed and ~16GB resident.

nok22kon 3mo ago
how exactly did you disabled it on Windows? I dont think it has an option for that.
- szmarczak 3mo ago
  Settings -> View advanced system settings -> Performance (Settings) -> Advanced -> Virtual memory (Change...) -> No paging file
  - 0x1d7 3mo ago
    This is almost always a bad idea. If no memory is available where a page file would make a difference, this leads to application crashes instead. A crash is (usually) worse than paging. Certain applications, Photoshop being the historical example, will outright fail to run with no page file present.
    - szmarczak 3mo ago
      > this leads to application crashes instead Same happens if the page file is full. In that case, why don't those programs use disk directly instead? No such problem would've ever occured if programs hadn't allocated more than they actually use.
      - 0x1d7 3mo ago
        Your argument falls flat when a page file can be multi-GB and automatically grow. And if your application admin was competent, memory monitoring would be part of the application monitoring stack. An application that grows in such a way (besides having backing stores for memory-mapped files, as well) will often perform so poorly that it requires addressing (adding RAM, looking for application faults, etc). A page file is insurance, one that can last you much longer than available system memory.
        szmarczak 3mo ago
        > memory monitoring would be part of the application monitoring stack You don't need it if you have everything allocated upfront. TigerBeetle does this, everybody else can. Using something like Rust is already a huge win when compared to shipping a browser or running Node.js. > Your argument falls flat when a page file can be multi-GB and automatically grow This doesn't solve the original issue and only masks the underlying problem.
        0x1d7 3mo ago
        > This doesn't solve the original issue and only masks the underlying problem. You're moving goal posts. No, a page file doesn't solve the problem of a misbehaving application, but it does solve the problem of an app crash because no more VAS allocation can be made. You should really dive into Windows Internals. Only misinformed gamers turn off page files.
      - toast0 3mo ago
        By default, windows uses an expandable page file. 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. > No such problem would've ever occured if programs hadn't allocated more than they actually use. That's part of the issue, but sometimes things do in fact use too much memory as well as allocate too much. Another part of the issue is that few programs are built to handle allocation failures. And then you have a metrics issue. There's not really a good metric to know when you're out of memory, other than performance collapse. If your applications don't use disk, it's not too hard; but when they do use disk, performance will collapse once there's insufficient memory to provide the disk caching needed. In my experience, adding a small swap and monitoring swap i/o can be pretty helpful, and a small swap doesn't tend to allow long thrashing when memory use grows. But that's not universal and everybody loves to hate swap these days.
        quotemstr 3mo ago
        > 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 and thereby make page-outs even more profitable.
        swinglock 3mo ago
        Windows does memory compression too.
        quotemstr 3mo ago
        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.
        3mo ago
  - tredre3 3mo ago
    That's disabling swap, not overcommit. Windows doesn't overcommit. It's one of the reason why it handles low memory situations so much more gracefully than Linux.
    - 0x1d7 3mo ago
      ^ The purpose of the system commit limit and commit charge is to track all uses of these resources to ensure they are never overcommitted — that is, that there is never more virtual address space defined than there is space to store its contents, either in RAM or in backing store (on disk). - Windows Internals, 7th Edition
- wongarsu 3mo ago
  Not overcommitting is Windows's default and only behavior A memory allocator can implement overcommit, because you can separate reserving virtual memory and having it backed by physical memory into two different system calls. But from the point of view of the kernel, any time it promises to give you physical memory that memory is backed either by RAM or by space reserved in the swap file
  - senfiaj 3mo ago
    As I understand, Windows can also lazily allocate pages, but it does after making sure the memory budget is adequate in a case of low physical RAM pressure and is guaranteed to be backed up by a page. But yeah, Linux approach is really sloppy.
- swinglock 3mo ago
  I don't think it has overcommit at all, at least that's the default. That would be why you don't have Windows OOM killer stories.
  - tredre3 3mo ago
    The reason you hear less about Window's OOM killer is simply because it works well. The Linux Kernel OOM killer kills random things. Userspace OOM killers are meant to improve this, and they work well in a server situation when you already know in advance what is likely to go haywire and what is safe to kill. But they don't work well on desktop (some of them are improving but it doesn't seem to be a priority). The Windows OOM killer by comparison usually kills something sensible (i.e. the program that is actually using all the memory), and asks the user for permission before killing it (when possible). You do see a lot of memes of situations where it fails.
    - nok22kon 3mo ago
      damn, good observation, when my data analysis python script goes wrong and allocates 24 GB of RAM on a 32 GB computer, it crashes (gets killed) with "out of memory" error. I've never seen something else getting killed
      - deleted 3mo ago
        [deleted]
      - frollogaston 3mo ago
        That's what I've seen Linux do too. What's different about how Windows chooses a process to kill?
        0x1d7 3mo ago
        Windows doesn't kill.
    - man8alexd 3mo ago
      > The Linux Kernel OOM killer kills random things. By default, the Linux kernel kills the largest process in the system (unless OOM adjust was applied).
sterwill 3mo ago
Does this result in programs more frequently erroring/crashing because they can't allocate? I don't know how well many of the programs I frequently use on my desktop (Firefox, GNOME desktop, JVM + IntelliJ, Slack, etc.) handle allocation failures. I'm not sure they would do much better than crash, but I know the default OOM killer settings work well for me. About once a year a real runaway process (usually a throwaway program I'm working on) gets OOM-killed, and that's fine with me.
- szmarczak 3mo ago
  > Does this result in programs more frequently erroring/crashing because they can't allocate? I run Firefox, VSCodium with LSP, Discord, Signal and there's still space left for a game like CS2. I'm not a heavy user by any means. > I'm not sure they would do much better than crash I have yet to see a program that silently handles allocation failures and doesn't crash. These days everything is coded to crash if no memory :( > About once a year a real runaway process (usually a throwaway program I'm working on) gets OOM-killed In my case it killed system critical processes with no way to recover. With disabled overcommit, it freezes for a while (usually for a minute or two), I close some random program of my choosing and then see in Resource Monitor what's eating my ram.
  - __s 3mo ago
    > I have yet to see a program that silently handles allocation failures and doesn't crash Postgres handles allocation failures
- fpoling 3mo ago
  Java allowed to handle out-of-memory rather well if one wanted to even 25 years ago. Basically one allocated a buffer on a startup taking 5% of memory that the application was supposed to use and made all threads to catch the oom exception. When handling that the buffer would be released, GC would be forced and a special flag would be set asking app to cancel any memory-intensive tasks until enough memory would be released and the buffer can be allocated again. It worked extremely well.
man8alexd 3mo ago
disabling overcommit is trading OOM for random program crashes due to the inability to handle ENOMEM. It also wastes a lot of system memory. https://unix.stackexchange.com/questions/797835/disabling-overcommitting-memory-seems-to-cause-allocs-to-fail-too-early-what-co/797888#797888 https://unix.stackexchange.com/questions/797835/disabling-ov...

nok22kon 3mo ago

how exactly did you disabled it on Windows? I dont think it has an option for that.

szmarczak 3mo ago
Settings -> View advanced system settings -> Performance (Settings) -> Advanced -> Virtual memory (Change...) -> No paging file
- 0x1d7 3mo ago
  This is almost always a bad idea. If no memory is available where a page file would make a difference, this leads to application crashes instead. A crash is (usually) worse than paging. Certain applications, Photoshop being the historical example, will outright fail to run with no page file present.
  - szmarczak 3mo ago
    > this leads to application crashes instead Same happens if the page file is full. In that case, why don't those programs use disk directly instead? No such problem would've ever occured if programs hadn't allocated more than they actually use.
    - 0x1d7 3mo ago
      Your argument falls flat when a page file can be multi-GB and automatically grow. And if your application admin was competent, memory monitoring would be part of the application monitoring stack. An application that grows in such a way (besides having backing stores for memory-mapped files, as well) will often perform so poorly that it requires addressing (adding RAM, looking for application faults, etc). A page file is insurance, one that can last you much longer than available system memory.
      - szmarczak 3mo ago
        > memory monitoring would be part of the application monitoring stack You don't need it if you have everything allocated upfront. TigerBeetle does this, everybody else can. Using something like Rust is already a huge win when compared to shipping a browser or running Node.js. > Your argument falls flat when a page file can be multi-GB and automatically grow This doesn't solve the original issue and only masks the underlying problem.
        0x1d7 3mo ago
        > This doesn't solve the original issue and only masks the underlying problem. You're moving goal posts. No, a page file doesn't solve the problem of a misbehaving application, but it does solve the problem of an app crash because no more VAS allocation can be made. You should really dive into Windows Internals. Only misinformed gamers turn off page files.
    - toast0 3mo ago
      By default, windows uses an expandable page file. 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. > No such problem would've ever occured if programs hadn't allocated more than they actually use. That's part of the issue, but sometimes things do in fact use too much memory as well as allocate too much. Another part of the issue is that few programs are built to handle allocation failures. And then you have a metrics issue. There's not really a good metric to know when you're out of memory, other than performance collapse. If your applications don't use disk, it's not too hard; but when they do use disk, performance will collapse once there's insufficient memory to provide the disk caching needed. In my experience, adding a small swap and monitoring swap i/o can be pretty helpful, and a small swap doesn't tend to allow long thrashing when memory use grows. But that's not universal and everybody loves to hate swap these days.
      - quotemstr 3mo ago
        > 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 and thereby make page-outs even more profitable.
        swinglock 3mo ago
        Windows does memory compression too.
        quotemstr 3mo ago
        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.
        3mo ago
- tredre3 3mo ago
  That's disabling swap, not overcommit. Windows doesn't overcommit. It's one of the reason why it handles low memory situations so much more gracefully than Linux.
  - 0x1d7 3mo ago
    ^ The purpose of the system commit limit and commit charge is to track all uses of these resources to ensure they are never overcommitted — that is, that there is never more virtual address space defined than there is space to store its contents, either in RAM or in backing store (on disk). - Windows Internals, 7th Edition
wongarsu 3mo ago
Not overcommitting is Windows's default and only behavior A memory allocator can implement overcommit, because you can separate reserving virtual memory and having it backed by physical memory into two different system calls. But from the point of view of the kernel, any time it promises to give you physical memory that memory is backed either by RAM or by space reserved in the swap file
- senfiaj 3mo ago
  As I understand, Windows can also lazily allocate pages, but it does after making sure the memory budget is adequate in a case of low physical RAM pressure and is guaranteed to be backed up by a page. But yeah, Linux approach is really sloppy.
swinglock 3mo ago
I don't think it has overcommit at all, at least that's the default. That would be why you don't have Windows OOM killer stories.
- tredre3 3mo ago
  The reason you hear less about Window's OOM killer is simply because it works well. The Linux Kernel OOM killer kills random things. Userspace OOM killers are meant to improve this, and they work well in a server situation when you already know in advance what is likely to go haywire and what is safe to kill. But they don't work well on desktop (some of them are improving but it doesn't seem to be a priority). The Windows OOM killer by comparison usually kills something sensible (i.e. the program that is actually using all the memory), and asks the user for permission before killing it (when possible). You do see a lot of memes of situations where it fails.
  - nok22kon 3mo ago
    damn, good observation, when my data analysis python script goes wrong and allocates 24 GB of RAM on a 32 GB computer, it crashes (gets killed) with "out of memory" error. I've never seen something else getting killed
    - deleted 3mo ago
      [deleted]
    - frollogaston 3mo ago
      That's what I've seen Linux do too. What's different about how Windows chooses a process to kill?
      - 0x1d7 3mo ago
        Windows doesn't kill.
  - man8alexd 3mo ago
    > The Linux Kernel OOM killer kills random things. By default, the Linux kernel kills the largest process in the system (unless OOM adjust was applied).

sterwill 3mo ago

Does this result in programs more frequently erroring/crashing because they can't allocate? I don't know how well many of the programs I frequently use on my desktop (Firefox, GNOME desktop, JVM + IntelliJ, Slack, etc.) handle allocation failures. I'm not sure they would do much better than crash, but I know the default OOM killer settings work well for me. About once a year a real runaway process (usually a throwaway program I'm working on) gets OOM-killed, and that's fine with me.

szmarczak 3mo ago
> Does this result in programs more frequently erroring/crashing because they can't allocate? I run Firefox, VSCodium with LSP, Discord, Signal and there's still space left for a game like CS2. I'm not a heavy user by any means. > I'm not sure they would do much better than crash I have yet to see a program that silently handles allocation failures and doesn't crash. These days everything is coded to crash if no memory :( > About once a year a real runaway process (usually a throwaway program I'm working on) gets OOM-killed In my case it killed system critical processes with no way to recover. With disabled overcommit, it freezes for a while (usually for a minute or two), I close some random program of my choosing and then see in Resource Monitor what's eating my ram.
- __s 3mo ago
  > I have yet to see a program that silently handles allocation failures and doesn't crash Postgres handles allocation failures
fpoling 3mo ago
Java allowed to handle out-of-memory rather well if one wanted to even 25 years ago. Basically one allocated a buffer on a startup taking 5% of memory that the application was supposed to use and made all threads to catch the oom exception. When handling that the buffer would be released, GC would be forced and a special flag would be set asking app to cancel any memory-intensive tasks until enough memory would be released and the buffer can be allocated again. It worked extremely well.

man8alexd 3mo ago

disabling overcommit is trading OOM for random program crashes due to the inability to handle ENOMEM. It also wastes a lot of system memory. https://unix.stackexchange.com/questions/797835/disabling-overcommitting-memory-seems-to-cause-allocs-to-fail-too-early-what-co/797888#797888 https://unix.stackexchange.com/questions/797835/disabling-ov...