On 21 Aug 2003 at 11:26, Andrew Sullivan wrote:
> On Thu, Aug 21, 2003 at 08:38:14PM +0530, Shridhar Daithankar wrote:
> > If a database is clean i.e. no dead tuple, an autovacuum daemon with 1 min
> > interval can achieve pretty much same result, isn't it?
>
> But we're talking about the case of large, busy databases that have
> already choked their disks. We have the same problem here in our
> test machines. We start running load tests, and with vacuums nicely
> scheduled and everything we start topping out on the performance
> pretty quickly, because of I/O bottlenecks on the database. We know
> the difference in I/O bandwidth between our test env. and the
> production env., so we can put in a fudge factor for this; but that's
> it.
Well, nothing can help if the database has dead tuples already. Sometime
somebody has to take time to run vacuum full and/or database reload to get a
clean state.
Point I am trying to make is to tune FSM and autovacuum frequency such that you
catch all the dead tuples in RAM, which is non-blocking operation at the
expense of some CPU power. I am sure 1 min autovacuum I suggested is waaay too
aggressive for any scheduled vacuum isn't it?
It would be really good if vacuum analyse gets lock only for pages it's
dealing. That way there would be minimum impact on rest of the system. I don't
know how it is done as of now.
Ideally a vacuum analyze could run in tight loops wasting minimum CPU. But that
is like making two poles of earth hug each other..
Bye
Shridhar
--
Bolub's Fourth Law of Computerdom: Project teams detest weekly progress
reporting because it so vividly manifests their lack of progress.