A comment on very large shared_buffers benchmarks
I tried to post a comment to Kenny Gorman’s post on Tuning for very large shared_buffers article, but it seems to have gone into the spam bucket. I was torn about whether it’s worth a separate post anyway, so this tipped me over the edge.
My question is what happens in the other 3 scenarios that weren’t measured? Namely,
- Test#4: buffered I/O and 20GB of shared_buffers
- Test#5: direct I/O and 500MB of shared_buffers
- Test#6: direct I/O and 2GB of shared_buffers
Without these, I’m unable to form an opinion on the article’s conclusions:
A modest gain can be had when using a very large (comparatively) shared_buffers setting when combining that change with direct I/O. The PostgreSQL cache does scale quite nicely up to at least a 20GB cache size when configured in this manner.
I’m also unclear on what the X-axis on the graph represents.
I can’t speak for Kenny, but a few of us in Portland are running some shared_buffers tests with a system donated to us by HP. The tests are not available yet – lots of data, and lots of graphs to make :)
Our notes from IO testing and initial Postgres testing are at: http://wiki.postgresql.org/wiki/HP_ProLiant_DL380_G5_Tuning_Guide
I’ll be presenting results from our Postgres testing at FOSDEM! These tests are with 8.3 so far. They take a long time, so we’re not sure we’ll get to 8.4 by then.
Selena Deckelmann
17 Dec 08 at 12:36 pm
Selena,
Interesting stuff. Are you planning to test VxFS and/or any combination of Direct I/O?
Kenny Gorman
6 Jan 09 at 7:46 pm
Hi Kenny,
No plans to test VxFS — we’re sticking to open source and non-restrictive EULAs for now :)
And re: Direct I/O — I’m assuming you mean enabling that in the filesystems. But I’m not sure how that would help Postgres performance at this time, as it wouldn’t take advantage of the cache being disabled.
-selena
Selena Deckelmann
6 Jan 09 at 8:19 pm