Date: Mon, 9 Jul 2007 15:53:08 -0500
From: "Jim C. Nasby" <decibel@decibel.org>
To: "Jignesh K. Shah" <J.K.Shah@Sun.COM>
Cc: Heikki Linnakangas <heikki@enterprisedb.com>,
	pgsql-performance@postgresql.org
Subject: Re: PostgreSQL publishes first real benchmark
Message-ID: <20070709205307.GP39272@nasby.net>
References: <46925AD9.9020208@sun.com> <469261EC.7080106@enterprisedb.com>
	<469274FC.8000506@sun.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="H4SyuGOnfnj3aJqJ"
Content-Disposition: inline
In-Reply-To: <469274FC.8000506@sun.com>
User-Agent: Mutt/1.5.13 (2006-08-11)


--H4SyuGOnfnj3aJqJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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

--H4SyuGOnfnj3aJqJ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (FreeBSD)

iD8DBQFGkqAzdO30qud8SkgRAjq3AKDkExYS8/ndi4rfdblETod9lPtziACdFwB+
c2RSUOXpYhMt2zTIHiF7ngQ=
=7dV5
-----END PGP SIGNATURE-----

--H4SyuGOnfnj3aJqJ--