Re: autovacuum stuck on a table for 18+ hours, consuming lots of CPU time

Поиск
Список
Период
Сортировка
От Lonni J Friedman
Тема Re: autovacuum stuck on a table for 18+ hours, consuming lots of CPU time
Дата
Msg-id CAP=oouHFZcXTpRQVU6t2T=c-A5q+p0uoMFs7aoC3uVwyCk3dZQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: autovacuum stuck on a table for 18+ hours, consuming lots of CPU time  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: autovacuum stuck on a table for 18+ hours, consuming lots of CPU time  (Robert Treat <rob@xzilla.net>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: autovacuum stuck on a table for 18+ hours, consuming lots of CPU time
Следующее
От: Robert Treat
Дата:
Сообщение: Re: autovacuum stuck on a table for 18+ hours, consuming lots of CPU time