From: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org> |
---|---|
To: | "Jignesh K(dot) Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM> |
Cc: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: PostgreSQL publishes first real benchmark |
Date: | 2007-07-09 20:53:08 |
Message-ID: | 20070709205307.GP39272@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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(at)decibel(dot)org
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
From | Date | Subject | |
---|---|---|---|
Next Message | Dolafi, Tom | 2007-07-09 21:48:21 | Re: rtree/gist index taking enormous amount of space in 8.2.3 |
Previous Message | Jonah H. Harris | 2007-07-09 20:46:32 | Re: Filesystem Direct I/O and WAL sync option |