Re: Pre-allocation of shared memory ...
От | Tom Lane |
---|---|
Тема | Re: Pre-allocation of shared memory ... |
Дата | |
Msg-id | 22159.1055467113@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Pre-allocation of shared memory ... ("Jeroen T. Vermeulen" <jtv@xs4all.nl>) |
Ответы |
Re: Pre-allocation of shared memory ...
Re: Pre-allocation of shared memory ... |
Список | pgsql-hackers |
"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. > 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
В списке pgsql-hackers по дате отправления: