[HACKERS] large page query
Hi, I posted this email on the other postgres lists but did not get a reply. So as a last resort, I came here. I hope somebody can help. I am looking into the impact of large page sizes on the performance of commercial workloads e.g databases,webserver,virtual machines etc. I was wondering if I could get to know whether Postgres administrators configure the Postgres DBMS with large page support for shared memory regions, specifically on the Solaris 9 and 10 OSes. My understanding is that since large pages (4 MB) are suitable for applications allocating large shared memory regions (databases for instance), Postgres would most definitely use the large page support. Is it a functionality placed into Postgres by the developers or the administrator has to configure the database to use it ? So in a nutshell, the questions are 1) Does Postgres use large page support ? On solaris 10 and the ultrasparc III processor, a large page is 4 MB. It significantly reduces the page table size of the application and a 1000 entry TLB can cover the entire memory 4G. 2) On Solaris 9 and 10, does Postgres rely on the MPSS support provided by the Operating system and relegate the job of figuring out what to allocate as a large page and what not to, when to allocate a large page and when not to etc to the Operating system? Or is it the case that the Postgres developers have written it judiciously and Postgres itself knows what to and what not to allocate as a large page ? The reason i ask this question is because, i know for a JVM, solaris 10 allocates large pages for the heap memory (this is default behavior, no runtime parameters needed when one runs the JVM. The OS is smart enough to figure this out by probably looking at what is the app that is running ) 3) In light of all this, do we know the performance difference between Postgres configured with no large pages vs Postgres configured with large pages. Your replies are highly appreciated. Hamza
Re: [HACKERS] large page query
On Mon, Nov 29, 2010 at 12:05 PM, Hamza Bin Sohail hsoh...@purdue.edu wrote: 1) Does Postgres use large page support ? On solaris 10 and the ultrasparc III processor, a large page is 4 MB. It significantly reduces the page table size of the application and a 1000 entry TLB can cover the entire memory 4G. 2) On Solaris 9 and 10, does Postgres rely on the MPSS support provided by the Operating system and relegate the job of figuring out what to allocate as a large page and what not to, when to allocate a large page and when not to etc to the Operating system? Or is it the case that the Postgres developers have written it judiciously and Postgres itself knows what to and what not to allocate as a large page ? The reason i ask this question is because, i know for a JVM, solaris 10 allocates large pages for the heap memory (this is default behavior, no runtime parameters needed when one runs the JVM. The OS is smart enough to figure this out by probably looking at what is the app that is running ) 3) In light of all this, do we know the performance difference between Postgres configured with no large pages vs Postgres configured with large pages. To the best of my knowledge, PostgreSQL has no configuration options to use large page support on any architecture. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] large page query
Hamza Bin Sohail hsoh...@purdue.edu wrote: I was wondering if I could get to know whether Postgres administrators configure the Postgres DBMS with large page support for shared memory regions You might be interested in a recent thread in the -hackers archives which starts with this post: http://archives.postgresql.org/message-id/28895.1290886...@sss.pgh.pa.us -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
