Skip site navigation (1) Skip section navigation (2)

Re: Report: Linux huge pages with Postgres

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Kenneth Marshall <ktm(at)rice(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Report: Linux huge pages with Postgres
Date: 2010-11-29 00:47:52
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Greg Stark <gsstark(at)mit(dot)edu> writes:
> On Mon, Nov 29, 2010 at 12:12 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Really you do want to scrape the value.

> Couldn't we just round the shared memory allocation down to a multiple
> of 4MB? That would handle all older architectures where the size is
> 2MB or 4MB.

Rounding *down* will not work, at least not without extremely invasive
changes to the shmem allocation code.  Rounding up is okay, as long as
you don't mind some possibly-wasted space.

> I see online that IA64 supports larger page sizes up to 256MB but then
> could we make it the user's problem if they change their hugepagesize
> to a larger value to pick a value of shared_buffers that will fit
> cleanly? We might need to rejigger things so that the shared memory
> segment is exactly the size of shared_buffers and any other shared
> data structures are in a separate segment though for that to work.

Two shmem segments would be a pretty serious PITA too, certainly a lot
more so than a few lines to read a magic number from /proc.

But this is all premature pending a demonstration that there's enough
potential gain here to be worth taking any trouble at all.  The one
set of numbers we have says otherwise.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Greg StarkDate: 2010-11-29 00:52:09
Subject: Re: profiling connection overhead
Previous:From: Fujii MasaoDate: 2010-11-29 00:45:49
Subject: Re: contrib: auth_delay module

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group