On Tuesday, August 12, 2014, pinker <pin...@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
