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

Re: Posix Shared Mem patch

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Daniel Farina <daniel(at)heroku(dot)com>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>,Andres Freund <andres(at)2ndquadrant(dot)com>,pgsql-hackers(at)postgresql(dot)org, Josh Berkus <josh(at)agliodbs(dot)com>
Subject: Re: Posix Shared Mem patch
Date: 2012-07-03 02:51:41
Message-ID: 20120703025141.GC25966@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Jun 29, 2012 at 04:03:40PM -0700, Daniel Farina wrote:
> On Fri, Jun 29, 2012 at 1:00 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> > On Fri, Jun 29, 2012 at 2:52 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> >> Hi All,
> >>
> >> In a *very* quick patch I tested using huge pages/MAP_HUGETLB for the mmap'ed
> >> memory.
> >> That gives around 9.5% performance benefit in a read-only pgbench run (-n -S -
> >> j 64 -c 64 -T 10 -M prepared, scale 200, 6GB s_b, 8 cores, 24GB mem).
> >>
> >> It also saves a bunch of memory per process due to the smaller page table
> >> (shared_buffers 6GB):
> >> cat /proc/$pid_of_pg_backend/status |grep VmPTE
> >> VmPTE:      6252 kB
> >> vs
> >> VmPTE:        60 kB
> > ... those results are just spectacular (IMO). nice!
> 
> That is super awesome.  Smallish databases with a high number of
> connections actually spend a considerable fraction of their
> otherwise-available-for-buffer-cache space on page tables in common
> cases currently.

I thought newer Linux kernels did huge pages automatically?  What Linux
kernel is this?

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2012-07-03 02:52:21
Subject: Re: Posix Shared Mem patch
Previous:From: Robert HaasDate: 2012-07-03 02:49:10
Subject: huge tlb support

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