pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Jim C. Nasby <decibel@decibel.org>
To: Jignesh K. Shah <J.K.Shah@Sun.COM>
Cc: Heikki Linnakangas <heikki@enterprisedb.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: PostgreSQL publishes first real benchmark
Date: Mon, 9 Jul 2007 15:53:08 -0500
Message-ID: <20070709205307.GP39272@nasby.net> (raw)
In-Reply-To: <469274FC.8000506@sun.com>
References: <46925AD9.9020208@sun.com>
	<469261EC.7080106@enterprisedb.com>
	<469274FC.8000506@sun.com>

On Mon, Jul 09, 2007 at 01:48:44PM -0400, Jignesh K. Shah wrote:
> 
> Hi Heikki,
> 
> Heikki Linnakangas wrote:
> >
> >That's really exciting news!
> >
> >I'm sure you spent a lot of time tweaking the settings, so let me ask 
> >you something topical:
> >
> >How did you end up with the bgwriter settings you used? Did you 
> >experiment with different values? How much difference did it make?
> >
> 
> Background writer is still a pain to get it right.. I say it is a 
> necessary evil since you are trying to balance it with trying to level 
> writes to the disks and  lock contentions caused by the writer itself to 
> the postgresql connections. Our typical problem will arise at the high 
> number of users where all users are suddenly locked due to the bgwriter 
> holding the locks.. Using the hotuser script (which uses pearl/Dtrace 
> combination) we ran quite a bit of numbers trying to see which ones 
> results in less  overall time spent in PGLock*  calls and yet gave good 
> uniform writes to the disks. After reaching the published settings,  
> everynow and then we would try playing with different values to see if 
> it improves but generally seemed to degrade if changed.. (Of course your 
> mileage will vary depending on config, workload, etc).
> 
> Still I believe the locking mechanism needs to be revisited at some 
> point since that seems to be the one which will eventually limit the 
> number of users in such a workload. (Specially if you dont hit the right 
> settings for your workload)

Do you know specifically what locks were posing the problem? I have a
theory that having individual backends run the clock sweep limits
concurrency and I'm wondering if you were seeing any of that. The lock
in question would be BufFreelistLock.
-- 
Jim Nasby                                      decibel@decibel.org
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

view thread (27+ messages)  latest in thread

Message-ID: <20070709205307.GP39272@nasby.net>
Permalink:  ../20070709205307.GP39272@nasby.net/
Also on:    postgresql.org/message-id/20070709205307.GP39272@nasby.net

 · 

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: decibel@decibel.org, J.K.Shah@Sun.COM, heikki@enterprisedb.com
  Subject: Re: PostgreSQL publishes first real benchmark
  In-Reply-To: <20070709205307.GP39272@nasby.net>

* 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