Re: autovacuum stuck on a table for 18+ hours, consuming lots of CPU time - Mailing list pgsql-general

From Lonni J Friedman
Subject Re: autovacuum stuck on a table for 18+ hours, consuming lots of CPU time
Date
Msg-id CAP=oouHFZcXTpRQVU6t2T=c-A5q+p0uoMFs7aoC3uVwyCk3dZQ@mail.gmail.com
Whole thread Raw
In response to Re: autovacuum stuck on a table for 18+ hours, consuming lots of CPU time  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: autovacuum stuck on a table for 18+ hours, consuming lots of CPU time  (Robert Treat <rob@xzilla.net>)
List pgsql-general
On Tue, Nov 22, 2011 at 7:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Lonni J Friedman <netllama@gmail.com> writes:
>> I suspect you're right.  I just ran strace against that PID again, and
>> now all the lseek & read FD's are referrring to a different number
>> (115), so that means its moved onto something new since I looked a few
>> hours ago?
>
>> Anyway, I think this is what you were referring to:
>> /proc/30188/fd/115 ->   /var/lib/pgsql/data/base/64793/72633.10
>
>> How do I correlate that file to an actual database object?
>
> 64793 is the pg_database.oid of the database, and 72633 is the
> pg_class.relfilenode value of the table/index.

Its definitely an index.    Thanks for your help, I just need to be
patient now that I understand how to better monitor this.

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: autovacuum stuck on a table for 18+ hours, consuming lots of CPU time
Next
From: Robert Treat
Date:
Subject: Re: autovacuum stuck on a table for 18+ hours, consuming lots of CPU time