Re: vacuum locking
От | Tom Lane |
---|---|
Тема | Re: vacuum locking |
Дата | |
Msg-id | 25480.1066872467@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: vacuum locking (Rob Nagler <nagler@bivio.biz>) |
Ответы |
Re: vacuum locking
|
Список | 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 по дате отправления: