Tgl wrote:
> > As I see it, this means the user-locks (and perhaps all
> > locks...?) eat around ~ 6k bytes memory each.
> 
> They're allocated in groups of 32, which would work out to close to
6k;
> maybe you were measuring the incremental cost of allocating the first
one?

I got my 6k figure by dividing 10000 into 64M, 10000 being the value
that crashed the server.  That's reasonable because doubling shared
buffers slightly more than doubled the crash value.

I was wondering how ~ 10k locks ran me out of shared memory when each
lock takes ~ 260b (half that, as you say) and I am running 8k buffers =
64M.

260 * 100 backends * 64 maxlocks = 1.7 M.  Sure, the hash table and
other stuff adds some...but this is no where near what it should take to
run me out.  

Am I just totally misunderstanding how to estimate locks memory
consumption?

Merlin

Wed, 29 Sep 2004 08:56:12 -0400
"Merlin Moncure" <merlin.moncure@rcsonline.com>
Re: shared memory release following failed lock acquirement. 
"Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
> I was wondering how ~ 10k locks ran me out of shared memory when each
> lock takes ~ 260b (half that, as you say) and I am running 8k buffers =
> 64M.

The number of buffers you have doesn't have anything to do with this.
The question is how much shared memory space is there for the lock
table, above and beyond what's used for everything else (such as
buffers).

I just went through and corrected some minor errors in the calculation
of shared memory block size (mostly stuff where the estimation code had
gotten out of sync with the actual work over time).  I now find that
with all-default configuration parameters I can create 7808 locks before
running out of shared memory, rather than the promised 6400.  (YMMV due
to platform-specific differences in MAXALIGN, sizeof(pointer), etc.)
This is coming from two places: LockShmemSize deliberately adds on 10%
slop factor to its calculation of the lock table size, and then
CreateSharedMemoryAndSemaphores adds on 100KB for safety margin.  Both
of those numbers are kinda pulled from the air, but I don't see a strong
reason to change them.  The other space calculations seem to be pretty
nearly dead-on.

			regards, tom lane

Wed, 29 Sep 2004 11:27:42 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: shared memory release following failed lock acquirement. 