Re: pgpgout/s without swapping--what does it mean?

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Kevin Goess <kgoess(at)bepress(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: pgpgout/s without swapping--what does it mean?
Date: 2014-03-18 06:04:22
Message-ID: CAMkU=1wALGMuYkbjytpNaOdmGHMT0cMQW27tH=AYG52UqDFNAg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Monday, March 17, 2014, Kevin Goess <kgoess(at)bepress(dot)com> 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Simon Riggs 2014-03-18 13:39:24 Re: High Level Committers Wanted
Previous Message Rich Shepard 2014-03-17 23:36:33 Re: Upgrade: 9.0.5->9.3.3