From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Pre-allocation of shared memory ... |
Date: | 2003-06-12 15:56:57 |
Message-ID: | 200306121556.h5CFuvm05184@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I have added the following sentence to the docs too:
Note, you will need enough swap space to cover all your memory
needs.
I still wish Linux would just fail the fork/malloc when memory is low,
rather than requiring swap for everything _or_ overcommitting. I wonder
if making a unified buffer cache just made that too hard to do.
---------------------------------------------------------------------------
Andrew Dunstan wrote:
>
> On this machine (RH9, kernel 2.4.20-18.9) the docs say (in
> /usr/src/linux-2.4/Documentation/vm/overcommit-accounting ):
>
> -----------------
> The Linux kernel supports four overcommit handling modes
>
> 0 - Heuristic overcommit handling. Obvious overcommits of
> address space are refused. Used for a typical system. It
> ensures a seriously wild allocation fails while allowing
> overcommit to reduce swap usage
>
> 1 - No overcommit handling. Appropriate for some scientific
> applications
>
> 2 - (NEW) strict overcommit. The total address space commit
> for the system is not permitted to exceed swap + half ram.
> In almost all situations this means a process will not be
> killed while accessing pages but only by malloc failures
> that are reported back by the kernel mmap/brk code.
>
> 3 - (NEW) paranoid overcommit The total address space commit
> for the system is not permitted to exceed swap. The machine
> will never kill a process accessing pages it has mapped
> except due to a bug (ie report it!)
> ----------------------
>
> So maybe
>
> sysctl -w vm.overcommit_memory=3
>
> is what's needed? I guess you might pay a performance hit for doing that,
> though.
>
> andrew
>
> > > Yeah, I see it in the Mandrake kernel. But it's not in stock 2.4.19,
> > > so you can't assume everybody has it.
> > >
> >
> > We had this problem on a recent version of good old Slackware.
> > I think we also had it on RedHat 8 or so.
> >
> > Doing this kind of killing is definitely a bad habit. I thought it had
> > it had to do with something else so my proposal for pre-allocation
> > seems to be pretty obsolete ;).
> >
> > Thanks a lot.
> >
> > Hans
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-06-12 15:58:44 | Re: Pre-allocation of shared memory ... |
Previous Message | Lamar Owen | 2003-06-12 15:49:07 | Re: [HACKERS] SAP and MySQL ... [and Benchmark] |