Re: vacuum in Postgresql 8.0.x slowing down the database

From: Vinubalaji Gopal <vgopal(at)abaca(dot)com>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: vacuum in Postgresql 8.0.x slowing down the database
Date: 2008-03-28 07:28:33
Message-ID: 20080327232833.4d84b68b@vinu-ubuntu.abaca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, 26 Mar 2008 13:02:13 -0700
"Joshua D. Drake" <jd(at)commandprompt(dot)com> wrote:

> The slowness is likely attributed to Vacuum's use of I/O. When vacuum
> is running what does iostat -k 10 say?

Seems to be higher than normal - here is the output with vacuum run
without the other queries and the default vacuum taking ~1 hr:

avg-cpu: %user %nice %system %iowait %steal %idle
13.30 0.00 4.50 25.91 0.00 56.29
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
md2 3356.94 2005.59 12945.45 20076 129584

avg-cpu: %user %nice %system %iowait %steal %idle
16.20 0.00 6.32 24.89 0.00 52.59

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
md2 461.70 667.20 1512.00 6672 15120

I don't know if the output helps much since the vacuum took some time
and I lost more than half of my iostat -k screen output. (I scrolled up
- but got only some of the data)

If vacuum does affect the io what are the ways to reduce the io during
vacuum (the delay and cost parameter did not help that much - should I
consider reducing the cost even further)? Should I consider
partitioning the table?

Thank you.

--
Vinu

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Laszlo Nagy 2008-03-28 09:05:58 Planning a new server - help needed
Previous Message Tom Lane 2008-03-28 05:55:56 Re: [COMMITTERS] pgsql: Fix TransactionIdIsCurrentTransactionId() to use binary search