Re: Initial 9.2 pgbench write results

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Ants Aasma <ants(dot)aasma(at)eesti(dot)ee>
Cc: Greg Smith <greg(at)2ndquadrant(dot)com>, simon(at)2ndquadrant(dot)com, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Initial 9.2 pgbench write results
Date: 2012-02-28 17:49:06
Message-ID: CA+TgmoZebOMzsFtBFC2gdSzRfd8kxASZgSm5h=AKCOOQLRbsog@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 28, 2012 at 11:46 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Feb 28, 2012 at 1:15 AM, Ants Aasma <ants(dot)aasma(at)eesti(dot)ee> wrote:
>> My hypothesis for the TPS regression is that it is due to write combining.
>> When the workload is mainly bound by I/O, every little bit that can be saved
>> helps the bottomline. Larger scalefactors don't get the benefit because
>> there is less write combining going on overall.
>
> This is an interesting hypothesis which I think we can test.  I'm
> thinking of writing a quick patch (just for testing, not for commit)
> to set a new buffer flag BM_BGWRITER_CLEANED to every buffer the
> background writer cleans.   Then we can keep a count of how often such
> buffers are dirtied before they're evicted, vs. how often they're
> evicted before they're dirtied.  If any significant percentage of them
> are redirtied before they're evicted, that would confirm this
> hypothesis.  At any rate I think the numbers would be interesting to
> see.

Patch attached.

I tried it on my laptop with a 60-second pgbench run at scale factor
100, and got this:

LOG: bgwriter_clean: 1387 evict-before-dirty, 10 dirty-before-evict
LOG: bgwriter_clean: 1372 evict-before-dirty, 10 dirty-before-evict
LOG: bgwriter_clean: 1355 evict-before-dirty, 10 dirty-before-evict
LOG: bgwriter_clean: 1344 evict-before-dirty, 8 dirty-before-evict
LOG: bgwriter_clean: 1418 evict-before-dirty, 8 dirty-before-evict
LOG: bgwriter_clean: 1345 evict-before-dirty, 7 dirty-before-evict
LOG: bgwriter_clean: 1339 evict-before-dirty, 6 dirty-before-evict
LOG: bgwriter_clean: 1362 evict-before-dirty, 9 dirty-before-evict

That doesn't look bad at all. Then I reset the stats, tried it again,
and got this:

LOG: bgwriter_clean: 3863 evict-before-dirty, 198 dirty-before-evict
LOG: bgwriter_clean: 3861 evict-before-dirty, 199 dirty-before-evict
LOG: bgwriter_clean: 3978 evict-before-dirty, 218 dirty-before-evict
LOG: bgwriter_clean: 3928 evict-before-dirty, 204 dirty-before-evict
LOG: bgwriter_clean: 3956 evict-before-dirty, 207 dirty-before-evict
LOG: bgwriter_clean: 3906 evict-before-dirty, 222 dirty-before-evict
LOG: bgwriter_clean: 3912 evict-before-dirty, 197 dirty-before-evict
LOG: bgwriter_clean: 3853 evict-before-dirty, 200 dirty-before-evict

OK, that's not so good, but I don't know why it's different. I'm not
sure I can reproduce the exact same scenario Greg is seeing - this is
totally different hardware - but I'll play around with it a little bit
more. Greg, if you happen to feel like testing this on one of your
problem cases I'd be interested in seeing what it spits out.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Attachment Content-Type Size
bgwriter_clean_stats.patch application/octet-stream 3.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-02-28 18:10:53 Re: Initial 9.2 pgbench write results
Previous Message karavelov 2012-02-28 17:27:45 Re: Initial 9.2 pgbench write results