Tom,
The platform is Redhat 7.0 with a 2.2.19 kernal.
The behavior is different from the 7.1 vacuum, in 7.1, processes would
just hang since they needed to access the table being vacuumed. So they
would hang as long as the vacuum took on a particular table. In 7.2
they proceed, and don't hang, but take a long time. So you could say
that 7.2 is better than 7.1, but my expectations where higher of 7.2. I
was expecting vacuum to be a benign background process that could run in
parallel with other transactions. That doesn't yet seem to be the case. I will continue to monitor my system and see
ifthis is reproducable. I will then try to get a backtrace if I find I have a reproducable case.
thanks,
--Barry
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. 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
>
>
