Re: problems with new vacuum (??)
От | Hannu Krosing |
---|---|
Тема | Re: problems with new vacuum (??) |
Дата | |
Msg-id | 3C32E73C.888F2274@tm.ee обсуждение исходный текст |
Ответ на | problems with new vacuum (??) (Barry Lind <barry@xythos.com>) |
Ответы |
Re: problems with new vacuum (??)
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | pgsql-hackers |
Tom Lane wrote: > > Barry Lind <barry@xythos.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@postgresql.org so that your > message can get through to the mailing list cleanly
В списке pgsql-hackers по дате отправления: