From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Rob Nagler <nagler(at)bivio(dot)biz> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: vacuum locking |
Date: | 2003-10-23 01:27:47 |
Message-ID: | 25480.1066872467@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Rob Nagler <nagler(at)bivio(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | CHEWTC | 2003-10-23 01:46:32 | Re: Postgresql performance |
Previous Message | Rob Nagler | 2003-10-22 23:32:12 | Re: vacuum locking |