That makes sense, so updates to rows that are already in memory, either in blocks in the kernel page cache or in blocks in the postgres cache, would trigger writes but not reads. Thanks for the sanity check.
On Mon, Mar 17, 2014 at 11:04 PM, Jeff Janes <jeff.janes@xxxxxxxxx> wrote:
On Monday, March 17, 2014, Kevin Goess <kgoess@xxxxxxxxxxx> wrote:
We had a big increase in load, iowait, and disk i/o on a dedicated database host the other night.Looking at the sar logs, the problem shows itself in a big increase in pgpgout/s, which I believe is postgres paging out parts of itself to disk?02:15:01 AM pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s pgscand/s pgsteal/s %vmeff...However, there isn't a corresponding increase in pages *in*, so if postgres is writing portions of itself out to disk, they can't be very important.As far as I can tell, pgpgout/s includes all data written to disk, not just process memory being paged. So it includes WAL and data files being written, for example due to bulk loads. Seems like a odd name for that parameter, and I don't know how it differs from bwrtn/s, other than the different units.If it is a bulk load, that would explain why it is not being read back in. Also, it could be that the data is needed, but when it is needed it is still in cache and so doesn't lead to disk reads. But it still needs to be written for durability reasons.Cheers,Jeff
Kevin M. Goess
Software Engineer
Berkeley Electronic Press
kgoess@xxxxxxxxxxx
510-665-1200 x179
www.bepress.com
bepress: sustainable scholarly publishing
