And that's with a brief test. For the read write test, if the test is longer the differences become considerably starker.
-
-
Show this threadThanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Thanks for the results. A few questions: 1) what OS? If Linux: 2) is any of this a result of kernel VM improvements? 3) for r/w is there more response time variance with 16gb because of writeback storms?
-
It's indeed linux. And I don't think it's really VM improvement depandant - I think this has been true for a long time. The response time for 24GB (see copy/paste correction upthread) is vastly better than for the other shared buffer settings, as there is no buffer replacement.
- 5 more replies
New conversation -
-
-
Ugh, correction, I used 24GB, not 16GB. Stupid factor of two snuck in while tweeting.
Show this threadThanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
It's due to double buffering leading to the whole working set fitting neither into kernel page cache, nor yet into postgres's shared_buffers. And it's close to the worst case for that, because there'll be substantial amounts of memory for that wasted, without too much benefit.
End of conversation
New conversation -
-
-
So new recommendation: any value but 8GB?
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
It would be great if you drop this info as a comment on https://postgresqlco.nf/en/doc/param/shared_buffers … :)
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Interesting, I already faced buffer_mapping contention on a huge production. After several tests I wrote a quick & dirty tool to replay the workload to reproduce the issue. With smaller s_b it was worse and much better with bigger. I tried until 16Gb.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.