Re: Posix Shared Mem patch
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Daniel Farina <daniel@heroku.com>
Cc: Merlin Moncure <mmoncure@gmail.com>, Andres Freund <andres@2ndquadrant.com>, pgsql-hackers@postgresql.org, Josh Berkus <josh@agliodbs.com>
Date: 2012-07-03T02:51:41Z
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@gmail.com> wrote: > > On Fri, Jun 29, 2012 at 2:52 PM, Andres Freund <andres@2ndquadrant.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@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +