Re: Pre-allocation of shared memory ...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Andrew Dunstan" <andrew(at)dunslane(dot)net>
Cc: "Kurt Roeckx" <Q(at)ping(dot)be>, "Matthew Kirkwood" <matthew(at)hairy(dot)beasts(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Pre-allocation of shared memory ...
Date: 2003-06-14 21:38:29
Message-ID: 9431.1055626709@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Andrew Dunstan" <andrew(at)dunslane(dot)net> writes:
> I *know* the latest RH kernel docs *say* they have paranoid mode that
> supposedly guarantees against OOM - it was me that pointed that out
> originally :-). I just checked on the latest sources (today it's RH8, kernel
> 2.4.20-18.8) to be doubly sure, and can't see the patches. (That would be
> really bad of RH, btw, if I'm correct - saying in your docs you support
> something that you don't)

I tried a direct test on my RHL 8.0 box, and was able to prove that
indeed the overcommit 2/3 modes do something, though whether they work
exactly as documented is another question.

I wrote this silly little test program to get an approximate answer
about the largest amount a program could malloc:

#include <stdio.h>
#include <stdlib.h>

int
main (int argc, char **argv)
{
size_t min = 1024; /* assume this'd work */
size_t max = -1; /* = max unsigned */
size_t sz;
void *ptr;

while ((max - min) >= 1024ul) {
sz = (((unsigned long long) max) + ((unsigned long long) min)) / 2;
ptr = malloc(sz);
if (ptr) {
free(ptr);
// printf("malloc(%lu) succeeded\n", sz);
min = sz;
} else {
// printf("malloc(%lu) failed\n", sz);
max = sz;
}
}

printf("Max malloc is %lu Kb\n", min / 1024);

return 0;
}

and got these results:

[root(at)rh1 tmp]# echo 0 > /proc/sys/vm/overcommit_memory
[root(at)rh1 tmp]# ./alloc
Max malloc is 1489075 Kb
[root(at)rh1 tmp]# echo 1 > /proc/sys/vm/overcommit_memory
[root(at)rh1 tmp]# ./alloc
Max malloc is 2063159 Kb
[root(at)rh1 tmp]# echo 2 > /proc/sys/vm/overcommit_memory
[root(at)rh1 tmp]# ./alloc
Max malloc is 1101639 Kb
[root(at)rh1 tmp]# echo 3 > /proc/sys/vm/overcommit_memory
[root(at)rh1 tmp]# ./alloc
Max malloc is 974179 Kb

So it's definitely doing something. /proc/meminfo shows

total: used: free: shared: buffers: cached:
Mem: 261042176 160456704 100585472 0 72015872 63344640
Swap: 1077501952 44974080 1032527872
MemTotal: 254924 kB
MemFree: 98228 kB
MemShared: 0 kB
Buffers: 70328 kB
Cached: 59244 kB
SwapCached: 2616 kB
Active: 102532 kB
Inact_dirty: 11644 kB
Inact_clean: 21840 kB
Inact_target: 27200 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 254924 kB
LowFree: 98228 kB
SwapTotal: 1052248 kB
SwapFree: 1008328 kB
Committed_AS: 77164 kB

It does appear that the limit in mode 3 is not too far from where
you'd expect (SwapTotal - Committed_AS), and mode 2 allows about
128M more, which is correct since there's 256 M of RAM.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2003-06-14 21:39:56 Re: Pre-allocation of shared memory ...
Previous Message Tom Lane 2003-06-14 21:16:56 Re: Pre-allocation of shared memory ...