From: | Jonathan Corbet <corbet(at)lwn(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Report: Linux huge pages with Postgres |
Date: | 2010-11-29 15:30:53 |
Message-ID: | 20101129083053.6ca281b9@bike.lwn.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, 27 Nov 2010 14:27:12 -0500
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> And the bottom line is: if there's any performance benefit at all,
> it's on the order of 1%. The best result I got was about 3200 TPS
> with hugepages, and about 3160 without. The noise in these numbers
> is more than 1% though.
>
> This is discouraging; it certainly doesn't make me want to expend the
> effort to develop a production patch. However, perhaps someone else
> can try to show a greater benefit under some other test conditions.
Just a quick note: I can't hazard a guess as to why you're not getting
better results than you are, but I *can* say that putting together a
production-quality patch may not be worth your effort regardless. There
is a nice "transparent hugepages" patch set out there which makes
hugepages "just happen" when it seems to make sense and the system can
support it. It eliminates the need for all administrative fiddling and
for any support at the application level.
This patch is invasive and has proved to be hard to merge. RHEL6 has it,
though, and I believe it will get in eventually. I can point you at the
developer involved if you'd like to experiment with this feature and see
what it can do for you.
jon
Jonathan Corbet / LWN.net / corbet(at)lwn(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-11-29 15:34:40 | Re: Report: Linux huge pages with Postgres |
Previous Message | Robert Haas | 2010-11-29 15:30:02 | Re: pg_execute_from_file review |