Tom Lane wrote: > "Jeroen T. Vermeulen" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
