Re: Supporting huge pages on Windows - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Supporting huge pages on Windows
Date
Msg-id CAEepm=1ypsieJAy5ig-EVN2r6goBMhjGHfSmFa-BekrVAjODbA@mail.gmail.com
Whole thread Raw
In response to Re: Supporting huge pages on Windows  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Responses Re: Supporting huge pages on Windows  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Wed, Sep 28, 2016 at 7:32 PM, Tsunakawa, Takayuki
<tsunakawa.takay@jp.fujitsu.com> wrote:
> From: Thomas Munro [mailto:thomas.munro@enterprisedb.com]
>> >  huge_pages=off: 70412 tps
>> >  huge_pages=on : 72100 tps
>>
>> Hmm.  I guess it could be noise or random code rearrangement effects.
>
> I'm not the difference was a random noise, because running multiple set of three runs of pgbench (huge_pages = on,
off,on, off, on...) produced similar results.  But I expected a bit greater improvement, say, +10%.  There may be
betterbenchmark model where the large page stands out, but I think pgbench is not so bad because its random data access
wouldcause TLB cache misses. 

Your ~2.4% number is similar to what was reported for Linux with 4GB
shared_buffers:

https://www.postgresql.org/message-id/20130913234125.GC13697%40roobarb.crazydogs.org

Later in that thread there was a report of a dramatic ~15% increase in
"best result" TPS, but that was with 60GB of shared_buffers on a
machine with 256GB of RAM:

https://www.postgresql.org/message-id/20131024060313.GA21888%40toroid.org

--
Thomas Munro
http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: pg_dump getBlobs query broken for 7.3 servers
Next
From: Andres Freund
Date:
Subject: Re: Supporting huge pages on Windows