Re: Invulnerable VACUUM process thrashing everything

From: Markus Schaber <schabi(at)logix-tt(dot)com>
To: "Jeffrey W(dot) Baker" <jwbaker(at)acm(dot)org>
Cc: pgperf <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Invulnerable VACUUM process thrashing everything
Date: 2006-01-05 11:29:59
Message-ID: 43BD0337.60000@logix-tt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Hi, Jeffrey,

Jeffrey W. Baker wrote:
> A few WEEKS ago, the autovacuum on my instance of pg 7.4 unilaterally
> decided to VACUUM a table which has not been updated in over a year and
> is more than one terabyte on the disk.

Hmm, maybe this is the Transaction ID wraparound emerging, and VACUUM is
freezing the rows.

Did you VACUUM FREEZE the table after the last modifications?

> # kill -HUP 15308
> # kill -INT 15308
> # kill -PIPE 15308

Did you try kill -TERM?

This always cleanly ended VACUUMing backends on our machines within seconds.

> I assume that if I kill this with SIGKILL, that will bring down every
> other postgres process, so that should be avoided. But surely there is
> a way to interrupt this. If I had some reason to shut down the
> instance, I'd be screwed, it seems.

Yes, SIGKILL will make the postmaster shut down all running backend
instances, the same as SIGSEGV and possibly a few others.

The reason is that the postmaster assumes some internal data structure
corruption in the shared memory pages is possible on an "unclean"
backend abort, and thus quits immediately to minimize the possibility of
those corruptions to propagate to the disks.

HTH,
Markus
--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS

Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Andy 2006-01-05 15:16:47 Improving Inner Join Performance
Previous Message Bruce Momjian 2006-01-05 00:39:42 Re: Stats collector performance improvement