The often repeated recommendation to not exceed 8GB/25% of RAM for shared buffers in postgres is wrong. For pgbench scale 1500, on laptop with fast SSD and 32GB of RAM, parallelism of 16. s_b of 1GB, 8GB, 16GB, using huge pages. r/o: 115k, 100k, 185k r/w: 16300, 15100, 21500
-
-
I was curious if the work by
@axboe helped Postgreshttps://lwn.net/Articles/682582/ … -
It reduces some latency spikes in the cases where our own writeback control is not enabled for the sources of dirty data (i.e. backend writes by default, or another *_flush_after setting disabled). It also costs a bit of throughput in some cases.
- 2 more replies
New conversation -
-
-
That's however more costly (but still most of the time beneficial) when there are a lot of buffer replacements done by backends, which is why backend_flush_after, the corresponding configuration for backends, is off by default. Which can lead to horrid jitter.
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.