Re: Pre-allocation of shared memory ...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Jon Lapham <lapham(at)extracta(dot)com(dot)br>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Pre-allocation of shared memory ...
Date: 2003-06-12 15:19:51
Message-ID: 9768.1055431191@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> What really kills [:-)] me is that they allocate memory assuming I will
> not be using it all, then terminate the executable in an unrecoverable
> way when I go to use the memory.

To be fair, I'm probably misstating things by referring to malloc().
The big problem probably comes from fork() with copy-on-write --- the
kernel has no good way to estimate how much of the shared address space
will eventually become private modified copies, but it can be forgiven
for wanting to make less than the worst-case assumption.

Still, if you are wanting to run a reliable server, I think worst-case
assumption is exactly what you want. Swap space is cheap, and there's
no reason you shouldn't have enough swap to support the worst-case
situation. If the swap area goes largely unused, that's fine.

The policy they're calling "paranoid overcommit" (don't allocate more
virtual memory than you have swap) is as far as I know the standard on
all Unixen other than Linux; certainly it's the traditional behavior.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-06-12 15:31:28 Re: Pre-allocation of shared memory ...
Previous Message Bruce Momjian 2003-06-12 15:05:12 Re: Pre-allocation of shared memory ...