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

Re: Potential memory usage issue

From: Bill Moran <wmoran(at)collaborativefusion(dot)com>
To: David Brain <dbrain(at)bandwidth(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Potential memory usage issue
Date: 2007-03-22 13:17:00
Message-ID: 20070322091700.9d1553e6.wmoran@collaborativefusion.com (view raw or flat)
Thread:
Lists: pgsql-performance
In response to David Brain <dbrain(at)bandwidth(dot)com>:
> 
> Thanks for the response.
> Bill Moran wrote:
> > In response to David Brain <dbrain(at)bandwidth(dot)com>:
> >> I recently migrated one of our large (multi-hundred GB) dbs from an 
> >> Intel 32bit platform (Dell 1650 - running 8.1.3) to a 64bit platform 
> >> (Dell 1950 - running 8.1.5).  However I am not seeing the performance 
> >> gains I would expect
> > 
> > What were you expecting?  It's possible that your expectations are
> > unreasonable.
> 
> Possibly - but there is a fair step up hardware performance wise from a 
> 1650 (Dual 1.4 Ghz PIII with U160 SCSI) to a 1950 (Dual, Dual Core 2.3 
> Ghz Xeons with SAS) - so I wasn't necessarily expecting much from the 
> 32->64 transition (except maybe the option to go > 4GB easily - although 
> currently we only have 4GB in the box), but was from the hardware 
> standpoint.

Ahh ... I didn't get that from your original message.

> I am curious as to why 'top' gives such different output on the two 
> systems - the datasets are large and so I know I benefit from having 
> high shared_buffers and effective_cache_size settings.

Have you done any actual queries on the new system?  PG won't use the
shm until it needs it -- and that doesn't occur until it gets a request
for data via a query.

Install the pg_bufferstats contrib module and take a look at how shared
memory is being use.  I like to use MRTG to graph shared buffer usage
over time, but you can just do a SELECT count(*) WHERE NOT NULL to see
how many buffers are actually in use.

> > Provide more information, for one thing.  I'm assuming from the top output
> > that this is some version of Linux, but more details on that are liable
> > to elicit more helpful feedback.
> > 
> Yes the OS is Linux - on the 1650 version 2.6.14, on the 1950 version 2.6.18

-- 
Bill Moran
Collaborative Fusion Inc.

wmoran(at)collaborativefusion(dot)com
Phone: 412-422-3463x4023

****************************************************************
IMPORTANT: This message contains confidential information and is
intended only for the individual named. If the reader of this
message is not an intended recipient (or the individual
responsible for the delivery of this message to an intended
recipient), please be advised that any re-use, dissemination,
distribution or copying of this message is prohibited. Please
notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The
sender therefore does not accept liability for any errors or
omissions in the contents of this message, which arise as a
result of e-mail transmission.
****************************************************************

In response to

Responses

pgsql-performance by date

Next:From: Mario WeilguniDate: 2007-03-22 13:26:51
Subject: Re: Performance of count(*)
Previous:From: David BrainDate: 2007-03-22 13:06:45
Subject: Re: Potential memory usage issue

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