Re: Tuning shared_buffers with ipcs ?

Tom Lane wrote:

>Doug Y <dylists(at)ptd(dot)net> writes:
>
>
>>Tom Lane wrote:
>>
>>
>>>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
>
>
Ok, that explains the number of arrays... max_connections / 16.

Thanks... my mind works better when I can associate actual settings to
effects like that. And I'm sure that performance takes a hit during out
back-up dump. We're in the process of migrating them to dedicated mirror
machine to run dumps/reports etc from crons so that it won't negatively
affect the DB servers that get queries from the web applications.

Thanks again for clarification.