Recent Features
| |||||||||||||
Memory overcommitMemory overcommitPosted Mar 10, 2011 21:49 UTC (Thu) by epa (subscriber, #39769)In reply to: Memory overcommit by rvfh Parent article: Delaying the OOM killer
If you needed to have the total amount of real memory you malloc, most systems would need twice as much RAM.Or just twice as much swap space - which is not an issue on a typical desktop or laptop hard disk these days. (On an SSD or mobile phone it may be different.) If you have a huge swapfile but no overcommit, and if some applications allocate lots of memory and then unexpectedly start using all the memory they asked for, then your system will start swapping and running slowly. If you just overcommit memory, then when apps start using all the memory they allocated the system will become unstable and processes will be killed without warning by the OOM killer. It's clear which is preferable.
(Log in to post comments)
Memory overcommit Posted Mar 11, 2011 0:37 UTC (Fri) by droundy (subscriber, #4559) [Link] If you just overcommit memory, then when apps start using all the memory they allocated the system will become unstable and processes will be killed without warning by the OOM killer. It's clear which is preferable.Surely you've run into the situation where you've been unable to log into a machine because it's swapping like crazy, and are thus unable to kill the offending process? Is that really preferable to being able to go in and fix things immediately? Of course, things are easier when you've got a desktop and are already logged in, but even then I've seen situations where just switching to a terminal took many, many minutes, not to suggest the possibility of opening a new terminal. The large majority of OOM-killer experiences I've had have been situations where there was a memory leak involved. In such cases, the OOM killer is usually quite good at identifying the culprit and killing it. If you add enough swap, then the system freezes up indefinitely (or until you're able to get a killall typed into a terminal). Not a huge improvement in my book. In any case, it's not clear which is preferable.
Memory overcommit Posted Mar 16, 2011 12:17 UTC (Wed) by epa (subscriber, #39769) [Link] You're right, it is sometimes preferable to have applications be killed rather than being unable to log into the machine. But even here the OOM killer seems like a useful sticking plaster rather than fixing the real problem. It would be better to have 5% of physical memory reserved for root (or for an interactive 'task manager' that lets you kill misbehaving apps), in the same way that 5% of disk space was traditionally reserved.If the I/O scheduler were a bit smarter, then the swapping activities of processes would count against their I/O usage, so a single bloated Firefox process would not be able to monopolize the disk to the exclusion of everything else. Similarly there could be more fairness in physical RAM allocation, so it wouldn't be possible for one app to consume all the physical memory pushing everything else into swap; it would be limited to say 80%. (This is reasonable for desktop systems, of course for servers or number-crunching you don't care so much about interactive performance so you'd increase that figure.)
Memory overcommit Posted Mar 16, 2011 17:43 UTC (Wed) by nix (subscriber, #2304) [Link]
I'd say that you want to require 5% or whatever for root-owned apps *that belong to a terminal*. This stops a maddened root-owned daemon from bloating up and leaving you unable to log in again.
Memory overcommit Posted Mar 11, 2011 7:10 UTC (Fri) by rvfh (subscriber, #31018) [Link]
Why use loads of swap space when I have 3GB of RAM to run a bunch of services?
A quick look at top:
So there are 689 MB of unused memory! Not to mention 1 GB+ of of cached stuff for the system to grab in case of need.
Now let's see the memory usage (top two):
So the two main memory users (systemsettings!?!) have committed more than half a gig of RAM, but use less than a quarter (I know these numbers are not perfect, but the idea remains).
And you want me to get rid of overcommit???
Memory overcommit Posted Mar 16, 2011 12:19 UTC (Wed) by epa (subscriber, #39769) [Link]
Isn't that the point? You have three gigabytes of RAM, more than enough to give every application all it needs and do so in a guaranteed way - not 'you can probably have this but you might be randomly killed later on depending on what else happens'.
|
|||||||||||||