Re: Dumping a database that is not accepting commands?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx> wrote:

On Tue, Sep 17, 2013 at 9:48 AM, Natalie Wenz <nataliewenz@xxxxxxxxxxx> 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?



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux