Re: long running commits
От | Robert Treat |
---|---|
Тема | Re: long running commits |
Дата | |
Msg-id | AANLkTi=0Q2L4VVHo4n+D7RDSzhuB17JvbWvJquSn1VE8@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: long running commits ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: long running commits
|
Список | pgsql-admin |
On Wed, Mar 2, 2011 at 2:04 PM, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: >> "Vaughn, Adam (IMS)" <VaughnA@imsweb.com> 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
В списке pgsql-admin по дате отправления: