Re: Pre-allocation of shared memory ...
От | Bruce Momjian |
---|---|
Тема | Re: Pre-allocation of shared memory ... |
Дата | |
Msg-id | 200306131325.h5DDPnI29011@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Pre-allocation of shared memory ... (Patrick Welche <prlw1@newn.cam.ac.uk>) |
Ответы |
Re: Pre-allocation of shared memory ...
|
Список | pgsql-hackers |
Patrick Welche wrote: > On Thu, Jun 12, 2003 at 10:10:02PM -0400, Bruce Momjian wrote: > > Tom Lane wrote: > > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > > You have to love that swap + 1/2 ram option --- when you need four > > > > possible options, there is something wrong with your approach. :-) > > > > > > I'm still wondering what the "no overcommit handling" option does, > > > exactly. > > > > I assume it does no kills, and allows you to commit until you run of of > > swap and hang. This might be the BSD 4.4 behavior, actually. > > ? I thought the idea of no overcommit was that your malloc fails ENOMEM > if there isn't enough memory free for your whole request, rather than > gambling that other processes aren't actually using all of theirs right now > and have pages swapped out. I don't see where the hang comes in.. I think there are two important memory cases: malloc() - should fail right away if it can't reserve the requested memory; assuming application request memory they don't use just seems dumb --- fix the bad apps. fork() - this is the tricky one because you don't know at fork time who is going to be sharing the data pages as read-only or doing an exec to overlay a new process, and who is going to be modifying them and need a private copy. I think only the fork case is tricky. -- 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
В списке pgsql-hackers по дате отправления: