From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Doug Y <dylists(at)ptd(dot)net> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Tuning shared_buffers with ipcs ? |
Date: | 2004-10-15 19:53:28 |
Message-ID: | 20131.1097870008@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Doug Y <dylists(at)ptd(dot)net> writes:
> Tom Lane wrote:
>> I have not seen any such claim, and I do not see any way offhand that
>> ipcs could help.
>>
> Directly from:
> http://www.varlena.com/varlena/GeneralBits/Tidbits/annotated_conf_e.html
> "As a rule of thumb, observe shared memory usage of PostgreSQL with
> tools like ipcs and determine the setting."
[ shrug ... ] So ask elein why she thinks that will help.
>> This might tell you something about how many concurrent backends you've
>> used, but nothing about how many shared buffers you need.
>>
> Thats strange, I know I've had more than 4 concurrent connections on
> that box... (I just checked and there were at least a dozen).
There is more than one per-backend semaphore per semaphore set, 16 per
set if memory serves; so the ipcs evidence points to a maximum of
between 49 and 64 concurrently active backends. It's not telling you a
darn thing about appropriate shared_buffers settings, however.
> A mirror DB with the same config also has the same basic output from
> ipcs, except that it has times for 11 of the 17 arrays slots and most
> of them are the time when we do our backup dump (which makes sense
> that it would require more memory at that time.)
That doesn't follow either. I think you may have some bottleneck that
causes client requests to pile up during a backup dump.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Sean Chittenden | 2004-10-15 20:09:01 | Re: mmap (was First set of OSDL Shared Mem scalability results, some wierdness ... |
Previous Message | Mike Rylander | 2004-10-15 19:45:11 | Re: Does PostgreSQL run with Oracle? |