On 08.02.2011 18:14, Kevin Grittner wrote:
I wrote:
The multiplier of 10 PredXactList structures per connection is
kind of arbitrary. It affects the point at which information is
pushed to the lossy summary, so any number from 2 up will work
correctly; it's a matter of performance and false positive rate.
We might want to put that on a GUC and default it to something
lower.
If the consensus is that we want to add this knob, I can code it up
today. If we default it to something low, we can knock off a large
part of the 2MB increase in shared memory used by SSI in the default
configuration. For those not using SERIALIZABLE transactions the
only impact is that less shared memory will be reserved for
something they're not using. For those who try SERIALIZABLE
transactions, the smaller the number, the sooner performance will
start to drop off under load -- especially in the face of a
long-running READ WRITE transaction. Since it determines shared
memory allocation, it would have to be a restart-required GUC.
I do have some concern that if this defaults to too low a number,
those who try SSI without bumping it and restarting the postmaster
will not like the performance under load very much. SSI performance
would not be affected by a low setting under light load when there
isn't a long-running READ WRITE transaction.
Hmm, comparing InitPredicateLocks() and PredicateLockShmemSize(), it
looks like RWConflictPool is missing altogether from the calculations in
PredicateLockShmemSize().
I added an elog to InitPredicateLocks() and PredicateLockShmemSize(), to
print the actual and estimated size. Here's what I got with
max_predicate_locks_per_transaction=10 and max_connections=100:
LOG: shmemsize 635467
LOG: actual 1194392
WARNING: out of shared memory
FATAL: not enough shared memory for data structure "shmInvalBuffer"
(67224 bytes requested)
On the other hand, when I bumped max_predicate_locks_per_transaction to
100, I got:
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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
