From: Tom Lane <tgl@sss.pgh.pa.us>
To: Josh Berkus <josh@agliodbs.com>
Cc: Alvaro Herrera <alvherre@commandprompt.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: User concurrency thresholding: where do I look?
Date: Thu, 19 Jul 2007 13:25:38 -0400
Message-ID: <12686.1184865938@sss.pgh.pa.us> (raw)
In-Reply-To: <200707190922.24497.josh@agliodbs.com>
References: <200707190828.59088.josh@agliodbs.com>
<20070719154912.GG6538@alvh.no-ip.org>
<200707190922.24497.josh@agliodbs.com>
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; and the fact that you can continue the curve upwards
says that you're not on the edge of running out. However I agree that
it's worth experimenting with those two parameters to see if the curve
moves around at all.
Another resource that might be interesting is the number of open files.
Also, have you tried watching vmstat or local equivalent to confirm that
the machine's not starting to swap?
regards, tom lane
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: tgl@sss.pgh.pa.us, josh@agliodbs.com, alvherre@commandprompt.com
Subject: Re: User concurrency thresholding: where do I look?
In-Reply-To: <12686.1184865938@sss.pgh.pa.us>
* 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