pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Scott Marlowe <scott.marlowe@gmail.com>
To: Greg Smith <gsmith@gregsmith.com>
Cc: Brad Nicholson <bnichols@ca.afilias.info>
Cc: Kevin Kempter <kevin@consistentstate.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Monitoring buffercache...
Date: Mon, 24 Nov 2008 21:54:00 -0700
Message-ID: <dcc563d10811242054y5edd2135i5eddae66203b0442@mail.gmail.com> (raw)
In-Reply-To: <Pine.GSO.4.64.0811242335040.1084@westnet.com>
References: <200811241143.57182.kevin@kevinkempterllc.com>
	<dcc563d10811241146l95302b1wd0e88756883e4401@mail.gmail.com>
	<1227556326.18990.98.camel@bnicholson-desktop>
	<dcc563d10811241324t116f6e71j4863632b2c0c09a5@mail.gmail.com>
	<Pine.GSO.4.64.0811242335040.1084@westnet.com>

On Mon, Nov 24, 2008 at 9:40 PM, Greg Smith <gsmith@gregsmith.com> wrote:
> On Mon, 24 Nov 2008, Scott Marlowe wrote:
>
>> My guess is that the period of time for which pg_buffercache takes locks
>> on the buffer map are short enough that it isn't a real big deal on a fast
>> enough server.
>
> As the server involved gets faster, the amount of time the locks are
> typically held for drops.
>
> As your shared_buffers allocation increases, that amount of time goes up.
>
> So how painful the overhead is depends on how fast your CPU is relative to
> how much memory is in it.  Since faster systems tend to have more RAM in
> them, too, it's hard to say whether the impact will be noticable.
>
> Also, noting that the average case isn't impacted much isn't the concern
> here.  The problem is how much having all partition locks held will increase
> impact worst-case latency.

True.  I was just looking to see how it impacted my servers.  Just
FYI, it's an 8 core opteron 2.1GHz with 32 Gig 667MHz DDR2 ram.  It
runs on a fast RAID-10 set (12 15k drives under an areca 1680, but I
don't know if that matters that much here.) It can pretty easily about
400 or so active transactions and still be responsive, but noticeably
slower.  At anything under about 50 or so transactions it's still
quite fast.

It's configured to have 8Gig of the 32Gig allocated as shared buffers,
and a buffercache query takes about 1 second to run.  Is the
shared_mem locked all that time?  And is it only locked against
writes?



view thread (9+ messages)  latest in thread

Message-ID: <dcc563d10811242054y5edd2135i5eddae66203b0442@mail.gmail.com>
Permalink:  ../dcc563d10811242054y5edd2135i5eddae66203b0442@mail.gmail.com/
Also on:    postgresql.org/message-id/dcc563d10811242054y5edd2135i5eddae66203b0442@mail.gmail.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: scott.marlowe@gmail.com, gsmith@gregsmith.com, bnichols@ca.afilias.info, kevin@consistentstate.com
  Subject: Re: Monitoring buffercache...
  In-Reply-To: <dcc563d10811242054y5edd2135i5eddae66203b0442@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox