Re: significant performance hit whenever autovacuum runs after upgrading from 9.0 -> 9.1

From: fche(at)redhat(dot)com (Frank Ch(dot) Eigler)
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Lonni J Friedman <netllama(at)gmail(dot)com>, Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>, Andy Colson <andy(at)squeakycode(dot)net>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: significant performance hit whenever autovacuum runs after upgrading from 9.0 -> 9.1
Date: 2012-05-24 21:20:36
Message-ID: y0maa0xe0nv.fsf@fche.csb
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> [...] 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 [...]

In case it helps, this systemtap run will report on the top few
time-sampled call graphs of post* processes:

# debuginfo-install -y postgresql
# stap -V [...Fedora16...]
Systemtap translator/driver (version 1.7/0.153 non-git sources)
# cat post-prof.stp
probe timer.profile {
if (substr(execname(),0,4) != "post") next
bt[sprint_ustack(ubacktrace())] <<< 1
}
probe end {
foreach ([s] in bt- limit 50) { println("\n",@count(bt[s]),":",s) }
}
global bt[20000]

# stap post-prof.stp -v -d /usr/bin/postgres -d /usr/bin/postmaster --ldd --all-modules --suppress-handler-errors
[wait awhile during workload]
^C

1390:index_getnext+0x1f9 [postgres]
IndexNext+0x56 [postgres]
ExecScan+0x14e [postgres]
ExecProcNode+0x228 [postgres]
ExecLimit+0xb8 [postgres]
ExecProcNode+0xd8 [postgres]
standard_ExecutorRun+0x14a [postgres]
PortalRunSelect+0x287 [postgres]
PortalRun+0x248 [postgres]
PostgresMain+0x754 [postgres]
ServerLoop+0x799 [postgres]
PostmasterMain+0x647 [postgres]
main+0x71e [postgres]
__libc_start_main+0xed [libc-2.14.90.so]
_start+0x29 [postgres]

935:__lseek_nocancel+0x7 [libc-2.14.90.so]
FileSeek+0x127 [postgres]
_mdnblocks+0x20 [postgres]
mdnblocks+0x6b [postgres]
get_relation_info+0x5e2 [postgres]
build_simple_rel+0x169 [postgres]
add_base_rels_to_query+0x83 [postgres]
query_planner+0x159 [postgres]
grouping_planner+0xc0b [postgres]
subquery_planner+0x5b4 [postgres]
standard_planner+0xe4 [postgres]
pg_plan_query+0x1b [postgres]
pg_plan_queries+0x54 [postgres]
PostgresMain+0x848 [postgres]
ServerLoop+0x799 [postgres]
PostmasterMain+0x647 [postgres]

721:__send+0x22 [libc-2.14.90.so]
internal_flush+0x3b [postgres]
pq_flush+0x22 [postgres]
ReadyForQuery+0x29 [postgres]
PostgresMain+0x49e [postgres]
ServerLoop+0x799 [postgres]
PostmasterMain+0x647 [postgres]
main+0x71e [postgres]
__libc_start_main+0xed [libc-2.14.90.so]
_start+0x29 [postgres]

431:recv+0x22 [libc-2.14.90.so]
secure_read+0x1c6 [postgres]
pq_recvbuf+0x5f [postgres]
pq_getbyte+0x15 [postgres]
PostgresMain+0x4bf [postgres]
ServerLoop+0x799 [postgres]
PostmasterMain+0x647 [postgres]
main+0x71e [postgres]
__libc_start_main+0xed [libc-2.14.90.so]
_start+0x29 [postgres]

380:__lseek_nocancel+0x7 [libc-2.14.90.so]
FileSeek+0x127 [postgres]
_mdnblocks+0x20 [postgres]
mdnblocks+0x6b [postgres]
estimate_rel_size+0x7c [postgres]
get_relation_info+0x121 [postgres]
build_simple_rel+0x169 [postgres]
add_base_rels_to_query+0x83 [postgres]
query_planner+0x159 [postgres]
grouping_planner+0xc0b [postgres]
subquery_planner+0x5b4 [postgres]
standard_planner+0xe4 [postgres]
pg_plan_query+0x1b [postgres]
pg_plan_queries+0x54 [postgres]
PostgresMain+0x848 [postgres]
ServerLoop+0x799 [postgres]
[...]

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Mark Dilger 2012-05-24 21:40:06 Re: FATAL: lock file "postmaster.pid" already exists
Previous Message Tom Lane 2012-05-24 19:57:48 Re: Re: significant performance hit whenever autovacuum runs after upgrading from 9.0 -> 9.1