| 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 |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christopher Kings-Lynne | 2002-01-02 03:36:53 | Re: [SQL] An easy question about creating a primary key |
| Previous Message | Barry Lind | 2002-01-02 00:31:38 | problems with new vacuum (??) |