Re: problems with new vacuum (??)
От | Tom Lane |
---|---|
Тема | Re: problems with new vacuum (??) |
Дата | |
Msg-id | 1135.1009933673@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | problems with new vacuum (??) (Barry Lind <barry@xythos.com>) |
Ответы |
Re: problems with new vacuum (??)
|
Список | pgsql-hackers |
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. 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
В списке pgsql-hackers по дате отправления: