@sednet - not quite; it sounds like you're confusing "overcommit" with "backing store". In the SunOS 4 days every page of virtual memory needed to be backed by a page of swap; so 128M RAM + 192M swap == 192M virtual memory. If you only had 64M of swap then you only had 64M of VM - less than physical RAM! So you always needed at least as much swap as you had physical memory, just to draw even. Thus the rule of thumb; "twice ram = swap"
Linux and pretty much every modern Unix doesn't do this, so this old rule of thumb isn't true. It's never been true on Linux. 128M RAM + 128M swap == 256M VM.
However, Linux does have a failure mode; overcommit allows you to allocate 300M of memory! It just hopes you don't really want to use all the memory you asked for... when a VM page is requested for actual use (rather than being reserved) that exceeds actual VM capacity then the OOM kicks in.
You can tune Linux overcommit with sysctl values:
Code:
vm.overcommit_memory = 0
vm.overcommit_ratio = 50
vm.oom_dump_tasks = 1
vm.oom_kill_allocating_task = 0
vm.panic_on_oom = 0
With overcommit turned off then the program that requests more memory is refused it at allocation time, rather than at use time.
So imagine the following:
char *a;
a=(char *)malloc(1024*1024*1024);
a[400]='a';
With overcommit turned off this program will require 1G of free VM to run in because the program has requested a malloc() of 1G. You'll need 128M RAM + 1G swap (close enough) to run this program. However the programs actual page usage is much much smaller than that; just a handful of pages so the machine won't actually be doing much paging, fortunately. With overcommit turned on, your program will run just fine and no one cares, even though we only have 128M RAM + 128M swap.
Now:
char *a;
int i;
a=(char *)malloc(1024*1024*1024);
for (i=0;i<1024*1024*1024) a[i]='a';
With overcommit turned on (the default) the program will slowly start to use up all 1G of VM. If you use up all your VM then the OOM will kick in and kill your program (or, potentially, another innocent program if that was the one that requested a new page).
You can see there are pro's and con's of the overcommit feature and there have been religious wars about it
With overcommit turned on, programs may run that otherwise wouldn't fit (JVM's may fit into this category with -Xms). But programs may be OOM-kill'd at any place, just because a new VM page is needed.
With overcommit turned off then programs requesting reservation of pages that aren't free will be refused and can (if properly coded) catch this case. How many programs are properly coded? Well, at least those that aren't will SISGSEGV
I won't say overcommit is necessarily bad; I'm not really a fan, though. I leave it turned on and try to scale my machines to never actually need swap
FAQ
Search
Members
Register
Login [ Anonymous ]
