Tom Lane wrote:
> "Jeroen T. Vermeulen" <jtv@xs4all.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@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073