On Tuesday, August 12, 2014, pinker <
pinker@onet.eu> wrote:
Yesterday I had an interesting discussion with my colleague about shared
buffers size for our new server. This machine (is dedicated for db) has got
512GB of RAM and database size is about 80GB, so he assumes that db will
never have to read from disk,
Do you ever plan on restarting this server? Doing maintenance? Applying security patches?
so there is no point to adjust read ahead
setting, because every block gonna be read from RAM. As I've red in Greg
Smith book, once a block is changed it will be written to a disk and buffers
page is marked as clean, which would mean than changes occur in the same
page as before? What if dirty page doesn't have enough space for another row
and row has to be written to another page? Is it still occurs in RAM? If
that's true all updates of FSM occurs in RAM as well?
None of that still should need to read from disk regularly once the database is warmed up.
What about buffers_clean and pg_clog then? Are those maintained completely
in RAM as well without direct read from disk at all?
To be precise, does the path to update and read updated row looks like a or
b?:
a). clean page (shared buffers) -> dirty page (shared buffers) -> to disk ->
read from disk -> shared buffers -> query
b). clean page (shared buffers) -> dirty page (shared buffers) -> to disk
& dirty page (shared buffers) -> clean page (shared buffers) -> query
More like b), but you are missing all the states that involve "clean in shared_buffers, dirty in FS cache" and such.
btw. 512MB if we assume up to 600 connection is a reasonable value?
Reasonable value for what?
Cheers,
Jeff