Re: PostgreSQL and HugePage

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: PostgreSQL and HugePage
Дата
Msg-id AANLkTikur--tTbD68aguYBzsWKjmvvUCdCOz5JFwN+Sy@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PostgreSQL and HugePage  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: PostgreSQL and HugePage  (Greg Stark <gsstark@mit.edu>)
Список pgsql-hackers
On Wed, Oct 20, 2010 at 7:10 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I believe that for the equivalent Solaris option, we just automatically
> enable it when available.  So there'd be no need for user documentation.
> However, I definitely *would* like to see some benchmarks proving that
> the change actually does something useful.  I've always harbored the
> suspicion that this is just a knob to satisfy people who need knobs to
> frob.

Well saving a few megabytes of kernel space memory isn't a bad thing.
But I think the major effect is on forking new processes. Having to
copy that page map is a major cost when you're talking about very
large memory footprints. While machine memory has gotten larger the 4k
page size hasn't. I don't think it's a big cost once all the processes
have been forked if you're reusing them beyond perhaps slightly more
efficient cache usage.


--
greg


В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: WIP: extensible enums
Следующее
От: Robert Haas
Дата:
Сообщение: Re: pg_upgrade patch application process, and move to /bin?