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
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 ... |