On 11/14/14, 5:00 PM, Mark Kirkwood wrote:
>
> as the 'rule of thumb' for setting shared_buffers. However I was recently benchmarking a machine with a lot of ram
(1TB)and entirely SSD storage [1], and that seemed quite happy with 50GB of shared buffers (better performance than
with8GB). Now shared_buffers was not the variable we were concentrating on so I didn't get too carried away and try
muchbigger than about 100GB - but this seems like a good thing to come out with some numbers for i.e pgbench read write
andread only tps vs shared_buffers 1 -> 100 GB in size.
What PG version?
One of the huge issues with large shared_buffers is the immense overhead you end up with for running the clock sweep,
andon most systems that overhead is born by every backend individually. You will only see that overhead if your
databaseis larger than shared bufers, because you only pay it when you need to evict a buffer. I suspect you'd actually
needa database at least 2x > shared_buffers for it to really start showing up.
> [1] I may be in a position to benchmark the machines these replaced at some not to distant time. These are the
previousgeneration (0.5TB ram, 32 cores and all SSD storage) but probably still good for this test.
Awesome! If there's possibility of developers getting direct access, I suspect folks on -hackers would be interested.
Ifnot but you're willing to run tests for folks, they'd still be interested. :)
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
