Re: long running commits

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

 



On Wed, Mar 2, 2011 at 2:04 PM, Kevin Grittner
<Kevin.Grittner@xxxxxxxxxxxx> wrote:
>> "Vaughn, Adam (IMS)" <VaughnA@xxxxxxxxxx> wrote:
>>
>> I made all of the changes you mentioned except for the
>> shared_buffers (which will require a downtime I have set for
>> tonight). I do have another question though, why did you pick 512
>> MB for the new setting of shared_buffers? Everything I've ever
>> read says that 25% of available RAM is a conservative value for
>> shared_buffers.
>
> Well, in general 25% may be the best for overall *throughput*, but
> it can often lead to latency spikes, so it depends on what you care
> about.  The curve of throughput against shared_buffers has gotten
> pretty close to horizontal by around 1GB in a lot of my tests.

Yeah, it's worth pointing out that either you (the OP) are reading the
wrong stuff, or interpreting it wrong. 25% is usually where people
will tell you to start, and then tune it *down* (change, measure,
asses, repeat). Won't work for every workload, but in general that's
the way to go.

Robert Treat
play: xzilla.net
work: omniti.com
hiring: l42.org/Lg

-- 
Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin



[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