Re: Tuning shared_buffers with ipcs ?
От | Tom Lane |
---|---|
Тема | Re: Tuning shared_buffers with ipcs ? |
Дата | |
Msg-id | 20131.1097870008@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Tuning shared_buffers with ipcs ? (Doug Y <dylists@ptd.net>) |
Ответы |
Re: Tuning shared_buffers with ipcs ?
|
Список | pgsql-performance |
Doug Y <dylists@ptd.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
В списке pgsql-performance по дате отправления: