Re: vacuum locking - Mailing list pgsql-performance

From Tom Lane
Subject Re: vacuum locking
Date
Msg-id 25480.1066872467@sss.pgh.pa.us
Whole thread Raw
In response to Re: vacuum locking  (Rob Nagler <nagler@bivio.biz>)
Responses Re: vacuum locking  (Andrew Sullivan <andrew@libertyrms.info>)
List pgsql-performance
Rob Nagler <nagler@bivio.biz> writes:
> Here's the vmstat 5 at a random time:

>    procs                      memory    swap          io     system         cpu
>  r  b  w   swpd   free   buff  cache  si  so    bi    bo   in    cs  us  sy  id
>  0  0  0 272372  38416  78220 375048   0   3     2     0    0     0   2   2   0
>  0  0  0 272372  30000  78320 375660   0   0    34   274  382   284   5   1  94
>  0  1  0 272372  23012  78372 375924   0   0    25   558  445   488   8   2  90
>  1  0  0 272368  22744  78472 376192   0   6   125   594  364   664   9   3  88

> And here's it during vacuum:

>    procs                      memory    swap          io     system         cpu
>  r  b  w   swpd   free   buff  cache  si  so    bi    bo   in    cs  us  sy  id
>  1  2  1 277292   9620  72028 409664  46  32  4934  4812 1697   966   8   4  88
>  0  3  0 277272   9588  72096 412964  61   0  7303  2478 1391   976   3   3  94
>  2  2  0 277336   9644  72136 393264 1326  32  2827  2954 1693  1519   8   3  89

The increased I/O activity is certainly to be expected, but what I find
striking here is that you've got substantial swap activity in the second
trace.  What is causing that?  Not VACUUM I don't think.  It doesn't have
any huge memory demand.  But swapping out processes could account for
the perceived slowdown in interactive response.

            regards, tom lane

pgsql-performance by date:

Previous
From: Rob Nagler
Date:
Subject: Re: vacuum locking
Next
From: CHEWTC@ap.nec.com.sg
Date:
Subject: Re: Postgresql performance