From: | Ryan Cumming <ryan(dot)cumming(at)neverbluemedia(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Trivial HugeTLB Benchmark |
Date: | 2007-03-04 02:25:02 |
Message-ID: | 4AFBB997355FD241B52AFBE393A62C360FF8E6@bling.NeverblueMedia.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hey,
Out of curiosity I benchmarked PostgreSQL 8.2.3 using huge pages for shared memory. Oracle claims fairly significant speedups with huge pages but I couldn't find any information on PostgreSQL.
I used the attached patch to enable huge pages on Linux. The test hardware is a dual Nocona Xeon 3.2Ghz with 4GB of RAM and two 15K 73GB Ultra320 disks in a software RAID-1. The box is running CentOS 4.4 for x86-64 and the vendor's stock 2.6.9 kernel. The relevant postgresql.conf settings are:
shared_buffers=160MB
work_mem=8MB
fsync=off
full_page_writes=off
effective_cache_size=3GB
I ran each pgbench after a fresh reboot. I used 85 huge pages reserved at boot for the huge page test, and none for the normal shared memory test.
Normal shared memory:
-bash-3.00$ pgbench -c 5 -t 10000
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 5
number of transactions per client: 10000
number of transactions actually processed: 50000/50000
tps = 1669.009344 (including connections establishing)
tps = 1669.941756 (excluding connections establishing)
Huge pages:
-bash-3.00$ pgbench -c 5 -t 10000
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 5
number of transactions per client: 10000
number of transactions actually processed: 50000/50000
tps = 1678.392138 (including connections establishing)
tps = 1679.268344 (excluding connections establishing)
Assuming that this is a representative benchmark, it looks like huge pages are a very slight (0.5%) performance win. I'm guessing that PostgreSQL doesn't benefit as much as Oracle due to its much less ridiculous shared memory size. That performance boost is almost certainly not worth the platform-specific code or administration overhead of hugetlb on Linux.
-Ryan
This electronic mail transmission and any accompanying attachments contain confidential information intended only for the use of the individual or entity named above. Any dissemination, distribution, copying or action taken in reliance on the contents of this communication by anyone other than the intended recipient is strictly prohibited. If you have received this communication in error please immediately delete the e-mail and either notify the sender at the above e-mail address or by telephone at 250.386.5323.
Attachment | Content-Type | Size |
---|---|---|
hugetlb-test.diff | text/x-patch | 801 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | William ZHANG | 2007-03-04 03:42:21 | ERROR: operator does not exist: integer !=- integer |
Previous Message | Andrew Dunstan | 2007-03-04 00:48:38 | Re: Arrays of Complex Types |