Re: Pre-allocation of shared memory ...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Pre-allocation of shared memory ...
Date: 2003-06-13 01:18:33
Message-ID: 22159.1055467113@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Jeroen T. Vermeulen" <jtv(at)xs4all(dot)nl> writes:
> Given the right allocation proportions, this may mean that in the end the
> kernel has no way to handle a shortage gracefully by causing fork() or
> allocations to fail.

Sure it does. All you need is a conservative allocation policy: fork()
fails if it cannot reserve enough swap space to guarantee that the new
process could write over its entire address space. Copy-on-write is
an optimization that reduces physical RAM usage, not virtual address
space or swap-space requirements.

Given that swap space is cheap, and that killing random processes is
obviously bad, it's not apparent to me why people think this is not
a good approach --- at least for high-reliability servers. And Linux
would definitely like to think of itself as a server-grade OS.

> After that, where do you go? Try to find a reasonable process to shoot
> in the head. From what I heard, although I haven't kept current, a lot
> of work went into selecting a "reasonable" process, so there will be some
> determinism.

Considering the frequency with which we hear of database backends
getting shot in the head, I'd say those heuristics need lots of work
yet. I'll take a non-heuristic solution for any system I have to
administer, thanks.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2003-06-13 01:33:01 Re: Pre-allocation of shared memory ...
Previous Message Andrew Dunstan 2003-06-13 01:07:12 Re: Pre-allocation of shared memory ...