Re: Re: significant performance hit whenever autovacuum runs after upgrading from 9.0 -> 9.1
От | Lonni J Friedman |
---|---|
Тема | Re: Re: significant performance hit whenever autovacuum runs after upgrading from 9.0 -> 9.1 |
Дата | |
Msg-id | CAP=oouFcp0WjuowKrJ_SJzeFrc50uEHGWgM7Zk-UxR8Ur_z4=Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: significant performance hit whenever autovacuum runs after upgrading from 9.0 -> 9.1 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: significant performance hit whenever autovacuum runs after upgrading from 9.0 -> 9.1
|
Список | pgsql-general |
On Thu, May 24, 2012 at 12:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Lonni J Friedman <netllama@gmail.com> writes: >> No, not lots of subqueries or ORDERing, and most queries only touch a >> single table. However, I'm honestly not sure that I'm following where >> you're going with this. The problem isn't triggered by explicit >> queries. I can disable all external access, and simply wait for >> autovacuum to kick off, and the box starts to die. > > Can you correlate the performance hit with any specific part of > autovacuum? In particular, I'm wondering if it matters whether vacuum > is cleaning tables or indexes --- it alternates between the two, and the > access patterns are a bit different. You could probably watch what the > autovac process is doing with strace to see what it's accessing. Is there something specific I should be looking for in the strace output, or is this just a matter of correlating PID and FD to pg_class.relfilenode ?
В списке pgsql-general по дате отправления: