Re: PostgreSQL 8.0.6 crash

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: PostgreSQL 8.0.6 crash
Дата
Msg-id 200602111725.k1BHPTn29203@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: PostgreSQL 8.0.6 crash  (Greg Stark <gsstark@mit.edu>)
Список pgsql-hackers
Greg Stark wrote:
> 
> Tom Lane <tgl@sss.pgh.pa.us> writes:
> 
> > Greg Stark <gsstark@mit.edu> writes:
> > > That's why merely allocating tons of swap doesn't necessarily protect you.
> > > It's still possible for a process (or several processes if you allocate more
> > > swap than you have address space) to mmap gigabytes of memory without touching
> > > it and then start touching those pages.
> > 
> > So?  If the swap exists to back that memory, there's no problem.  It
> > might be slow, but it will not fail.
> 
> Sure, but there's no way to know how much swap you need. No matter how much
> swap you allocate these processes can allocate more pages of untouched RAM and
> then blow up.
> 
> Of course realistically allocating 4G of swap is enough to deal with something
> like Postgres where you're not being maliciously attacked. One process on ia32
> can't accidentally allocate more than 4G of ram.
> 
> I was just trying to clarify the situation since someone made some comment
> about it having to do with memory being swapped out and then finding nowhere
> to swap in when needed. That's not exactly what's happening.

I guess the fundamental issue is whether Linux requires all mmap()'ed
file contents to be in memory, or whether it pushes data to disk and
unmaps it as it runs low on memory.  I don't know the answer to that.

--  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 по дате отправления:

Предыдущее
От: "Magnus Hagander"
Дата:
Сообщение: Re: Upcoming re-releases
Следующее
От: Tom Lane
Дата:
Сообщение: Re: PostgreSQL 8.0.6 crash