Re: requested shared memory size overflows size_t - Mailing list pgsql-performance

From Bob Lunney
Subject Re: requested shared memory size overflows size_t
Date
Msg-id 584872.74177.qm@web39702.mail.mud.yahoo.com
Whole thread Raw
In response to requested shared memory size overflows size_t  ("Uwe Bartels" <uwe.bartels@gmail.com>)
Responses Re: requested shared memory size overflows size_t
List 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
machinerunning 64-bit Ubuntu and only PostgreSQL, I'd start by allocating 4 Gb to shared_buffers.  That should leave
morethan enough room for the OS and file system cache.  Then I'd begin testing by measuring response times of
representativequeries 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
thesoftware, setting a couple of GUCs and running it. 

Bob

--- On Thu, 6/10/10, Tom Wilcox <hungrytom@gmail.com> wrote:

> From: Tom Wilcox <hungrytom@gmail.com>
> Subject: Re: [PERFORM] requested shared memory size overflows size_t
> To: "Bob Lunney" <bob_lunney@yahoo.com>
> Cc: "Robert Haas" <robertmhaas@gmail.com>, pgsql-performance@postgresql.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@gmail.com> 
> wrote:
> >
> >   
> >> From: Robert Haas<robertmhaas@gmail.com>
> >> Subject: Re: [PERFORM] requested shared memory
> size overflows size_t
> >> To: "Bob Lunney"<bob_lunney@yahoo.com>
> >> Cc: pgsql-performance@postgresql.org,
> "Tom Wilcox"<hungrytom@googlemail.com>
> >> Date: Wednesday, June 9, 2010, 9:49 PM
> >> On Wed, Jun 2, 2010 at 9:26 PM, Bob
> >> Lunney<bob_lunney@yahoo.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
> >>
> >>     
> >
> >
> >   
>
>




pgsql-performance by date:

Previous
From: Amit Khandekar
Date:
Subject: Re: query hangs
Next
From: David Jarvis
Date:
Subject: Re: Analysis Function