Re: data on devel code perf dip

On Thu, 2005-08-11 at 22:11 -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > >> O_DIRECT is only being used for WAL page writes (or I sure hope so
> > >> anyway), so shared_buffers should be irrelevant.
> >
> > > Uh, O_DIRECT really just enables when open_sync is used, and I assume
> > > that is not used for writing dirty buffers during a checkpoint.
> >
> > I double-checked that O_DIRECT is really just used for WAL, and only
> > when the sync mode is open_sync or open_datasync. So it seems
> > impossible that it affected a run with mode fdatasync. What seems the
> > best theory at the moment is that the grouped-WAL-write part of the
> > patch doesn't work so well as we thought.
>
> Yes, that's my only guess. Let us know if you want the patch to test,
> rather than pulling CVS before and after the patch was applied.

I tried the pull we have from 8/28/05, which should not have the Wal
O-DIRECT patch or the WAL grouping patch (I believe that markw check
this for me).

Unfortunately the performance is just as bad as run 59. So it looks
like those patches are not my immediate problem.

While you think about that, I'm going to pull the development code
from July 18, and run it again with oprofile.

I'm still very concerned about what I'm seeing in the oprofile:
namely: .CreateLWLocks is the second highest entry for postgres.
http://developer.osdl.org/maryedie/DBT2_PGSQL/59/oprofile.txt

It is still the second highest entry in the run I just did.
Why are there so many "Creates"? Shouldn't there just be mostly
calls that gab a LW lock and release it? Mark and I looked
through the code at what the CreateLWLocks subroutine does
and found the note inserted below. Since the connections are
established at the very beginning, and this run went on for
30 more minutes, I dont understand why so many creates happened.
Can you explain this?

* This is called by the postmaster or by a standalone backend.
* It is also called by a backend forked from the postmaster in the
* EXEC_BACKEND case. In the latter case, the shared memory segment
* already exists and has been physically attached to, but we have to
* initialize pointers in local memory that reference the shared
structures,
* because we didn't inherit the correct pointer values from the
postmaster
* as we do in the fork() scenario. The easiest way to do that is to
run
* through the same code as before. (Note that the called routines
mostly
* check IsUnderPostmaster, rather than EXEC_BACKEND, to detect this
case.
* This is a bit code-wasteful and could be cleaned up.)
*
* If "makePrivate" is true then we only need private memory, not shared
* memory. This is true for a standalone backend, false for a
postmaster.

TIA.

>
--
Mary Edie Meredith
Initiative Manager
Open Source Development Labs
maryedie(at)hotmail(dot)com
503-906-1942