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

Re: problems with new vacuum (??)

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Barry Lind <barry(at)xythos(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: problems with new vacuum (??)
Date: 2002-01-02 10:55:56
Message-ID: 3C32E73C.888F2274@tm.ee (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> 
> 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.

They drive each other to the ground too ;(

When I tried to run the new vacuum concurrently with a pgbench in hope 
to make it perform better for large number of updates (via removing the 
need to scan large number of dead tuples) 1 concurrent vacuum was able
to 
make 128 pgbench backends more than twice as slow as they were without
vacuum. 
And this is an extra slowdown from another 2-3X slowdown due to dead
tuples 
(got from comparing speed on VACUUM FULL db and db aftre doing ~10k 
pgbench transactions)

> 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.

Have you any ideas how to distinguish between interactive and
non-interactive
disk I/O coming from postgresql backends ?

Can I for example nice the vacuum'ing backend without getting the 
"reverse priority" effects ?

> > 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
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly

In response to

Responses

pgsql-hackers by date

Next:From: Karel ZakDate: 2002-01-02 11:03:24
Subject: datetime error?
Previous:From: Holger KrugDate: 2002-01-02 09:26:52
Subject: Feature proposal: generalizing deferred trigger events

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