From: Alvaro Herrera <alvherre@commandprompt.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Josh Berkus <josh@agliodbs.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: User concurrency thresholding: where do I look?
Date: Thu, 19 Jul 2007 13:37:04 -0400
Message-ID: <20070719173704.GA12084@alvh.no-ip.org> (raw)
In-Reply-To: <12686.1184865938@sss.pgh.pa.us>
References: <200707190828.59088.josh@agliodbs.com>
<20070719154912.GG6538@alvh.no-ip.org>
<200707190922.24497.josh@agliodbs.com>
<12686.1184865938@sss.pgh.pa.us>
Tom Lane wrote:
> Josh Berkus <josh@agliodbs.com> writes:
> > Alvaro,
> >> Have you messed with max_connections and/or max_locks_per_transaction
> >> while testing this? The lock table is sized to max_locks_per_xact times
> >> max_connections, and shared memory hash tables get slower when they are
> >> full. Of course, the saturation point would depend on the avg number of
> >> locks acquired per user, which would explain why you are seeing a lower
> >> number for some users and higher for others (simpler/more complex
> >> queries).
>
> > That's an interesting thought. Let me check lock counts and see if this is
> > possibly the case.
>
> AFAIK you'd get hard failures, not slowdowns, if you ran out of lock
> space entirely;
Well, if there still is shared memory available, the lock hash can
continue to grow, but it would slow down according to this comment in
ShmemInitHash:
* max_size is the estimated maximum number of hashtable entries. This is
* not a hard limit, but the access efficiency will degrade if it is
* exceeded substantially (since it's used to compute directory size and
* the hash table buckets will get overfull).
For the lock hash tables this max_size is
(MaxBackends+max_prepared_xacts) * max_locks_per_xact.
So maybe this does not make much sense in normal operation, thus not
applicable to what Josh Berkus is reporting.
However I was talking to Josh Drake yesterday and he told me that
pg_dump was spending some significant amount of time in LOCK TABLE when
there are lots of tables (say 300k).
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: alvherre@commandprompt.com, tgl@sss.pgh.pa.us, josh@agliodbs.com
Subject: Re: User concurrency thresholding: where do I look?
In-Reply-To: <20070719173704.GA12084@alvh.no-ip.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox