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

Re: Report: Linux huge pages with Postgres

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:42:28
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, Nov 29, 2010 at 12:12 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I would expect that you can just iterate through the size possibilities
>> pretty quickly and just use the first one that works -- no /proc
>> groveling.
> It's not really that easy, because (at least on the kernel version I
> tested) it's not the shmget that fails, it's the later shmat.  Releasing
> and reacquiring the shm segment would require significant code
> restructuring, and at least on some platforms could produce weird
> failure cases --- I seem to recall having heard of kernels where the
> release isn't instantaneous, so that you could run up against SHMMAX
> for no apparent reason.  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.

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.


In response to


pgsql-hackers by date

Next:From: YourfriendDate: 2010-11-29 00:44:37
Subject: Feature request: INSERT .... ON DUPLICATE UPDATE ....
Previous:From: Tom LaneDate: 2010-11-29 00:42:23
Subject: Re: Rethinking representation of sort/hash semantics in queries and plans

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