On 2016-06-03 13:47:58 -0400, Robert Haas wrote: > On Fri, Jun 3, 2016 at 1:43 PM, Andres Freund <and...@anarazel.de> wrote: > >> I really don't get it. There's nothing in any set of guidelines for > >> setting shared_buffers that I've ever seen which would cause people to > >> avoid this scenario. > > > > The "roughly 1/4" of memory guideline already mostly avoids it? It's > > hard to constantly re-dirty a written-back page within 30s, before the > > 10% (background)/20% (foreground) limits apply; if your shared buffers > > are larger than the 10%/20% limits (which only apply to *available* not > > total memory btw). > > I've always heard that guideline as "roughly 1/4, but not more than > about 8GB" - and the number of people with more than 32GB of RAM is > going to just keep going up.
I think that upper limit is wrong. But even disregarding that: To hit the issue in that case you have to access more data than shared_buffers (8GB), and very frequently re-dirty already dirtied data. So you're basically (on a very rough approximation) going to have to write more than 8GB within 30s (256MB/s). Unless your hardware can handle that many mostly random writes, you are likely to hit the worst case behaviour of pending writeback piling up and stalls. > > I'm inclined to give up and disable backend_flush_after (not the rest), > > because it's new and by far the "riskiest". But I do think it's a > > disservice for the majority of our users. > > I think that's the right course of action. I wasn't arguing for > disabling either of the other two. Noah was... Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
