Re: SSI patch version 14

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: <simon(at)2ndQuadrant(dot)com>,<markus(at)bluegap(dot)ch>, <drkp(at)csail(dot)mit(dot)edu>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SSI patch version 14
Date: 2011-02-08 22:04:39
Message-ID: 4D516997020000250003A67C@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:

> LOG: shmemsize 3153112
> LOG: actual 2339864
>
> Which is a pretty big overestimate, percentage-wise. Taking
> RWConflictPool into account in PredicateLockShmemSize() fixes the
> underestimate, but makes the overestimate correspondingly larger.
> I've never compared the actual and estimated shmem sizes of other
> parts of the backend, so I'm not sure how large discrepancies we
> usually have, but that seems quite big.

I found two things which probably explain that:

(1) When HTABs are created, there is the max_size, which is what
the PredicateLockShmemSize function must use in its calculations,
and the init_size, which is what will initially be allocated (and
so, is probably what you see in the usage at the end of the
InitPredLocks function). That's normally set to half the maximum.

(2) The predicate lock and lock target initialization code was
initially copied and modified from the code for heavyweight locks.
The heavyweight lock code adds 10% to the calculated maximum size.
So I wound up doing that for PredicateLockTargetHash and
PredicateLockHash, but didn't do it for SerializableXidHassh.
Should I eliminate this from the first two, add it to the third, or
leave it alone?

So if the space was all in HTABs, you might expect shmemsize to be
110% of the estimated maximum, and actual (at the end of the init
function) to be 50% of the estimated maximum. So the shmemsize
would be (2.2 * actual) at that point. The difference isn't that
extreme because the list-based pools now used for some structures
are allocated at full size without padding.

In addition to the omission of the RWConflictPool (which is a
biggie), the OldSerXidControlData estimate was only for a *pointer*
to it, not the structure itself. The attached patch should correct
the shmemsize numbers.

-Kevin

Attachment Content-Type Size
ssi-shmemsize.patch text/plain 1.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2011-02-08 22:07:11 Re: Extensions versus pg_upgrade
Previous Message Dimitri Fontaine 2011-02-08 22:03:14 Re: Extensions support for pg_dump, patch v27