Re: Dumping a database that is not accepting commands?

Поиск
Список
Период
Сортировка
От Natalie Wenz
Тема Re: Dumping a database that is not accepting commands?
Дата
Msg-id 2EE7C659-6FA5-409D-8401-3F8A22E9DF3A@ebureau.com
обсуждение исходный текст
Ответ на Re: Dumping a database that is not accepting commands?  (bricklen <bricklen@gmail.com>)
Список pgsql-admin
No…  the shared_buffers value is just a legacy value that never got changed (the shmmax value in sysctl is still 1073741824).  When I set up the new database, I set the shared_buffers to 25% of system memory, so 12GB. (And since the new database is on 9.3, I didn't have to adjust the sysctl value for shmmax! Happy day!)

We used to have maintenance_work_mem set to something smaller, but we bumped that up after…<coughs>… the last time this database shut itself down to avoid wraparound in March 2012. We were hoping that would help speed the recovery at that time. Not sure if it did, but we left it that way afterward anyway.


On Sep 17, 2013, at 2:02 PM, bricklen <bricklen@gmail.com> wrote:

On Tue, Sep 17, 2013 at 9:48 AM, Natalie Wenz <nataliewenz@ebureau.com> wrote:
 maintenance_work_mem            | 10GB
 shared_buffers                  | 128MB

maintenance_work_mem seems pretty high, and shared_buffers seems really low.  Out of curiousity, were those set as a product of internal testing which determined those were effective settings?


В списке pgsql-admin по дате отправления:

Предыдущее
От: bricklen
Дата:
Сообщение: Re: Dumping a database that is not accepting commands?
Следующее
От: Natalie Wenz
Дата:
Сообщение: Re: Dumping a database that is not accepting commands?