Re: Tuning shared_buffers with ipcs ?

From: Doug Y <dylists(at)ptd(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Tuning shared_buffers with ipcs ?
Date: 2004-10-15 21:18:12
Message-ID: 41703E94.3030800@ptd.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2004-10-15 21:22:26 Re: mmap (was First set of OSDL Shared Mem scalability results, some wierdness ...
Previous Message Mark Wong 2004-10-15 20:39:47 Re: mmap (was First set of OSDL Shared Mem scalability results, some wierdness ...