Re: Pre-allocation of shared memory ...

Tom Lane wrote:
> "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.

BSD used to require full swap behind all RAM. I am not sure if that was
changed in BSD 4.4 or in later BSD/OS releases, but it is no longer
true. I think now it can use RAM or swap as reserved backing store for
fork page modifications. However, when the system runs of of swap, it
hangs!

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

You have to love that swap + 1/2 ram option --- when you need four
possible options, there is something wrong with your approach. :-)

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