Getting rid of AtEOXact_Buffers (was Re: [Testperf-general] Re: [PERFORM] First set of OSDL Shared Memscalability results, some wierdness ...)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org, pgsql-performance(at)postgreSQL(dot)org
Subject: Getting rid of AtEOXact_Buffers (was Re: [Testperf-general] Re: [PERFORM] First set of OSDL Shared Memscalability results, some wierdness ...)
Date: 2004-10-16 16:54:17
Message-ID: 4664.1097945657@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

I wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> First off, two test runs with OProfile are available at:
>> http://khack.osdl.org/stp/298124/
>> http://khack.osdl.org/stp/298121/

> Hmm. The stuff above 1% in the first of these is

> Counted CPU_CLK_UNHALTED events (clocks processor is not halted) with a unit mask of 0x00 (No unit mask) count 100000
> samples % app name symbol name
> ...
> 920369 2.1332 postgres AtEOXact_Buffers
> ...

> In the second test AtEOXact_Buffers is much lower (down around 0.57
> percent) but the other suspects are similar. Since the only difference
> in parameters is shared_buffers (36000 vs 9000), it does look like we
> are approaching the point where AtEOXact_Buffers is a problem, but so
> far it's only a 2% drag.

It occurs to me that given the 8.0 resource manager mechanism, we could
in fact dispense with AtEOXact_Buffers, or perhaps better turn it into a
no-op unless #ifdef USE_ASSERT_CHECKING. We'd just get rid of the
special case for transaction termination in resowner.c and let the
resource owner be responsible for releasing locked buffers always. The
OSDL results suggest that this won't matter much at the level of 10000
or so shared buffers, but for 100000 or more buffers the linear scan in
AtEOXact_Buffers is going to become a problem.

We could also get rid of the linear search in UnlockBuffers(). The only
thing it's for anymore is to release a BM_PIN_COUNT_WAITER flag, and
since a backend could not be doing more than one of those at a time,
we don't really need an array of flags for that, only a single variable.
This does not show in the OSDL results, which I presume means that their
test case is not exercising transaction aborts; but I think we need to
zap both routines to make the world safe for large shared_buffers
values. (See also
http://archives.postgresql.org/pgsql-performance/2004-10/msg00218.php)

Any objection to doing this for 8.0?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Fuhr 2004-10-16 16:56:00 Re: PL/Python: How do I use result methods?
Previous Message Joe Conway 2004-10-16 16:48:47 Re: [HACKERS] Networking feature for postgresql...

Browse pgsql-performance by date

  From Date Subject
Next Message Josh Berkus 2004-10-16 21:18:26 Re: Getting rid of AtEOXact_Buffers (was Re: [Testperf-general] Re: [PERFORM] First set of OSDL Shared Memscalability results, some wierdness ...)
Previous Message Bruce Momjian 2004-10-16 01:22:03 Re: mmap (was First set of OSDL Shared Mem scalability results,