On Fri, Jun 29, 2012 at 3: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
>
> Additionally it has the advantage that top/ps/... output under linux now looks
> like:
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 10603 andres 20 0 6381m 4924 1952 R 21 0.0 0:28.04 postgres
>
> i.e. RES now actually shows something usable... Which is rather nice imo.
>
> I don't have the time atm into making this something useable, maybe somebody
> else want to pick it up? Looks pretty worthwile investing some time.
>
> Because of the required setup we sure cannot make this the default but...
So, considering that there is required setup, it seems that the
obvious thing to do here is add a GUC: huge_tlb_pages (boolean).
The other alternative is to try with MAP_HUGETLB and, if it fails, try
again without MAP_HUGETLB.
Thoughts?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company