From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | "Ed L(dot)" <pgsql(at)bluepolka(dot)net> |
Cc: | pgsql-general(at)postgresql(dot)org, "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
Subject: | Re: autovac hung/blocked |
Date: | 2006-11-15 13:30:56 |
Message-ID: | 20061115133056.GL30115@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Ed L. wrote:
> Well, I think we clearly have an HPUX CPU bottleneck (long pri
> queue, high cpu utilization, high user cpu %, lots of processes
> "blocked on pri").
>
> It seems to get worst and slow all queries down across the board
> when autovac tries to vacuum a 15GB table. I'm guessing this is
> flushing the OS/DB caches, exacerbating the CPU bottleneck.
>
> I'm also not sure what to do about it beyond the customer buying
> some politically/financially expensive CPUs.
I suggest turning autovac off for that particular table, and doing the
vacuum during off-peak hours.
> The table in
> question appears to be the pathological case for vacuum: very
> large with lots of frequent UPDATEs. It's essentially a log
> table.
A big log table where the log entries are being updated? Certainly
sounds like a recipe for vacuum headaches.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias.Pitzl | 2006-11-15 13:44:46 | Question about query optimization |
Previous Message | Rick Schumeyer | 2006-11-15 13:28:36 | SQL subquery question |