Skip site navigation (1) Skip section navigation (2)

Re: requested shared memory size overflows size_t

From: Bob Lunney <bob_lunney(at)yahoo(dot)com>
To: Tom Wilcox <hungrytom(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: requested shared memory size overflows size_t
Date: 2010-06-11 06:25:47
Message-ID: 584872.74177.qm@web39702.mail.mud.yahoo.com (view raw or flat)
Thread:
Lists: pgsql-performance
Tom,

First off, I wouldn't use a VM if I could help it, however, sometimes you have to make compromises.  With a 16 Gb machine running 64-bit Ubuntu and only PostgreSQL, I'd start by allocating 4 Gb to shared_buffers.  That should leave more than enough room for the OS and file system cache.  Then I'd begin testing by measuring response times of representative queries with significant amounts of data.

Also, what is the disk setup for the box?  Filesystem?  Can WAL files have their own disk?  Is the workload OLTP or OLAP, or a mixture of both?  There is more that goes into tuning a PG server for good performance than simply installing the software, setting a couple of GUCs and running it.

Bob

--- On Thu, 6/10/10, Tom Wilcox <hungrytom(at)gmail(dot)com> wrote:

> From: Tom Wilcox <hungrytom(at)gmail(dot)com>
> Subject: Re: [PERFORM] requested shared memory size overflows size_t
> To: "Bob Lunney" <bob_lunney(at)yahoo(dot)com>
> Cc: "Robert Haas" <robertmhaas(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
> Date: Thursday, June 10, 2010, 10:45 AM
> Thanks guys. I am currently
> installing Pg64 onto a Ubuntu Server 64-bit installation
> running as a VM in VirtualBox with 16GB of RAM accessible.
> If what you say is true then what do you suggest I do to
> configure my new setup to best use the available 16GB (96GB
> and native install eventually if the test goes well) of RAM
> on Linux.
> 
> I was considering starting by using Enterprise DBs tuner to
> see if that optimises things to a better quality..
> 
> Tom
> 
> On 10/06/2010 15:41, Bob Lunney wrote:
> > True, plus there are the other issues of increased
> checkpoint times and I/O, bgwriter tuning, etc.  It may
> be better to let the OS cache the files and size
> shared_buffers to a smaller value.
> > 
> > Bob Lunney
> > 
> > --- On Wed, 6/9/10, Robert Haas<robertmhaas(at)gmail(dot)com> 
> wrote:
> > 
> >    
> >> From: Robert Haas<robertmhaas(at)gmail(dot)com>
> >> Subject: Re: [PERFORM] requested shared memory
> size overflows size_t
> >> To: "Bob Lunney"<bob_lunney(at)yahoo(dot)com>
> >> Cc: pgsql-performance(at)postgresql(dot)org,
> "Tom Wilcox"<hungrytom(at)googlemail(dot)com>
> >> Date: Wednesday, June 9, 2010, 9:49 PM
> >> On Wed, Jun 2, 2010 at 9:26 PM, Bob
> >> Lunney<bob_lunney(at)yahoo(dot)com>
> >> wrote:
> >>      
> >>> Your other option, of course, is a nice 64-bit
> linux
> >>>        
> >> variant, which won't have this problem at all.
> >> 
> >> Although, even there, I think I've heard that
> after 10GB
> >> you don't get
> >> much benefit from raising it further.  Not
> sure if
> >> that's accurate or
> >> not...
> >> 
> >> -- Robert Haas
> >> EnterpriseDB: http://www.enterprisedb.com
> >> The Enterprise Postgres Company
> >> 
> >>      
> > 
> > 
> >    
> 
> 


      

Responses

pgsql-performance by date

Next:From: Leonardo FDate: 2010-06-11 07:43:16
Subject: Re: Error with GIT Repository
Previous:From: Amit KhandekarDate: 2010-06-11 05:09:34
Subject: Re: query hangs

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group