Skip site navigation (1) Skip section navigation (2)

Re: problems with new vacuum (??)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Barry Lind <barry(at)xythos(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: problems with new vacuum (??)
Date: 2002-01-02 01:07:53
Message-ID: 1135.1009933673@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Barry Lind <barry(at)xythos(dot)com> writes:
> But while this vacuum was running the rest of the system was performing 
> very poorly.  Opperations that usually are subsecond, where taking 
> minutes to complete.

Is this any different from the behavior of 7.1 vacuum?  Also, what
platform are you on?

I've noticed on a Linux 2.4 box (RH 7.2, typical commodity-grade PC
hardware) that vacuum, pgbench, or almost any I/O intensive operation
drives interactive performance into the ground.  I have not had an
opportunity to try to characterize the problem, but I suspect Linux's
disk I/O scheduler is not bright enough to prioritize interactive
operations.

> 2001-12-31 22:16:40 [20655]  DEBUG:  recycled transaction log file 
> 000000010000009A

> The interesting thing (at least in my mind) is that these messages were 
> produced by all of the other postgres processes, not by the vacuum 
> process.

No surprise, as they're coming from the checkpoint process(es).

> The second issue I noticed was that the vacuum process later just hung. 

You sure you just didn't wait long enough?

There was a deadlock condition found in 7.2b4 recently, but I am not
convinced that it could affect VACUUM.  Anyway, if you can replicate
the problem then please attach to the stuck process with gdb and provide
a stack backtrace.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Christopher Kings-LynneDate: 2002-01-02 03:36:53
Subject: Re: [SQL] An easy question about creating a primary key
Previous:From: Barry LindDate: 2002-01-02 00:31:38
Subject: problems with new vacuum (??)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group