Re: stats collector suddenly causing lots of IO

От: Tom Lane
Тема: Re: stats collector suddenly causing lots of IO
Дата: ,
Msg-id: 11152.1271436528@sss.pgh.pa.us
(см: обсуждение, исходный текст)
Ответ на: Re: stats collector suddenly causing lots of IO  (Josh Kupershmidt)
Ответы: Re: stats collector suddenly causing lots of IO  (Scott Carey)
Re: stats collector suddenly causing lots of IO  (Josh Kupershmidt)
Список: pgsql-performance

Скрыть дерево обсуждения

stats collector suddenly causing lots of IO  (Chris, )
 Re: stats collector suddenly causing lots of IO  (Cédric Villemain, )
 Re: stats collector suddenly causing lots of IO  (Alvaro Herrera, )
 Re: stats collector suddenly causing lots of IO  (Tom Lane, )
 Re: stats collector suddenly causing lots of IO  (Josh Kupershmidt, )
  Re: stats collector suddenly causing lots of IO  (Tom Lane, )
   Re: stats collector suddenly causing lots of IO  (Josh Kupershmidt, )
    Re: stats collector suddenly causing lots of IO  (Tom Lane, )
     Re: stats collector suddenly causing lots of IO  (Josh Kupershmidt, )
      Re: stats collector suddenly causing lots of IO  (Tom Lane, )
       Re: stats collector suddenly causing lots of IO  (Scott Carey, )
        Re: stats collector suddenly causing lots of IO  (Scott Carey, )
       Re: stats collector suddenly causing lots of IO  (Josh Kupershmidt, )
        Re: stats collector suddenly causing lots of IO  (Greg Smith, )
         Re: stats collector suddenly causing lots of IO  (Josh Kupershmidt, )
          Re: stats collector suddenly causing lots of IO  (Greg Smith, )
          Re: stats collector suddenly causing lots of IO  (Tom Lane, )
           Re: stats collector suddenly causing lots of IO  (Josh Kupershmidt, )
 Re: stats collector suddenly causing lots of IO  (Tom Lane, )
 Re: stats collector suddenly causing lots of IO  (Tom Lane, )
  Re: stats collector suddenly causing lots of IO  (Tom Lane, )

Josh Kupershmidt <> writes:
> On Fri, Apr 16, 2010 at 11:41 AM, Tom Lane <> wrote:
>> Wow. �Well, we have a smoking gun here: for some reason, autovacuum
>> isn't running, or isn't doing its job if it is. �If it's not running
>> at all, that would explain failure to prune the stats collector's file
>> too.

> Hrm, well autovacuum is at least trying to do work: it's currently
> stuck on those bloated pg_catalog tables, of course. Another developer
> killed an autovacuum of pg_attribute (or maybe it was pg_attrdef)
> after it had been running for two weeks. See current pg_stat_activity
> output attached, which shows the three autovacuum workers running plus
> two manual VACUUM ANALYZEs I started yesterday.

Two weeks?  What have you got the autovacuum cost delays set to?

Once you're up to three AV workers, no new ones can get launched until
one of those finishes or is killed.  So that would explain failure to
prune the stats collector's tables (the tabpurge code is only run during
AV worker launch).  So what we need to figure out is why it's taking so
obscenely long to vacuum these tables ...

            regards, tom lane


В списке pgsql-performance по дате сообщения:

От: Josh Kupershmidt
Дата:
Сообщение: Re: stats collector suddenly causing lots of IO
От: Віталій Тимчишин
Дата:
Сообщение: Re: Planner not using column limit specified for one column for another column equal to first