From: | "Benjamin Krajmalnik" <kraj(at)illumen(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: Autovacuum stopped running |
Date: | 2010-05-03 03:17:04 |
Message-ID: | F4E6A2751A2823418A21D4A160B68988614367@fletch.stackdump.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
OK.
This happened again on another server with these same settings.
I did not see any long running transaction, and the autovacuum launch
process was running.
> -----Original Message-----
> From: Benjamin Krajmalnik
> Sent: Saturday, May 01, 2010 5:22 PM
> To: 'Tom Lane'
> Cc: Kevin Grittner; pgsql-admin(at)postgresql(dot)org
> Subject: RE: [ADMIN] Autovacuum stopped running
>
> # - Cost-Based Vacuum Delay -
>
> #vacuum_cost_delay = 0ms # 0-100 milliseconds
> #vacuum_cost_page_hit = 1 # 0-10000 credits
> #vacuum_cost_page_miss = 10 # 0-10000 credits
> #vacuum_cost_page_dirty = 20 # 0-10000 credits
> vacuum_cost_limit = 10000 # 1-10000 credits
>
>
#----------------------------------------------------------------------
> --------
> # AUTOVACUUM PARAMETERS
>
#----------------------------------------------------------------------
> --------
>
> #autovacuum = on # Enable autovacuum subprocess?
'on'
> # requires track_counts to also
be on.
> #log_autovacuum_min_duration = -1 # -1 disables, 0 logs all
actions
> and
> # their durations, > 0 logs only
> # actions running at least this
number
> # of milliseconds.
> autovacuum_max_workers = 10 # max number of autovacuum
> subprocesses
> #autovacuum_naptime = 1min # time between autovacuum runs
> #autovacuum_vacuum_threshold = 50 # min number of row updates
before
> # vacuum
> #autovacuum_analyze_threshold = 50 # min number of row updates
before
> # analyze
> #autovacuum_vacuum_scale_factor = 0.2 # fraction of table size
> before vacuum
> #autovacuum_analyze_scale_factor = 0.1 # fraction of table size
> before analyze
> #autovacuum_freeze_max_age = 200000000 # maximum XID age before
> forced vacuum
> # (change requires restart)
> #autovacuum_vacuum_cost_delay = 20ms # default vacuum cost delay
> for
> # autovacuum, in milliseconds;
> # -1 means use vacuum_cost_delay
> #autovacuum_vacuum_cost_limit = -1 # default vacuum cost limit for
> # autovacuum, -1 means use
> # vacuum_cost_limit
>
>
> > -----Original Message-----
> > From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> > Sent: Saturday, May 01, 2010 5:10 PM
> > To: Benjamin Krajmalnik
> > Cc: Kevin Grittner; pgsql-admin(at)postgresql(dot)org
> > Subject: Re: [ADMIN] Autovacuum stopped running
> >
> > "Benjamin Krajmalnik" <kraj(at)illumen(dot)com> writes:
> > > TO be truthful, I did not check that.
> > > I arrived at the conclusion because although I have 10 autovacuum
> > > threads, none of the tables had been autoanalyzed or autovacuumed
> in
> > > hours (and due to the nature of the activity they do so every
> > minute).
> > > If I ever see this behavior now I know what to check for :) Thx.
> >
> > We've seen one or two previous reports that suggested that the
> autovac
> > launcher might have stopped launching workers, but it hasn't been
> > reproducible. Are you using any nonstandard parameters for
> autovacuum?
> >
> > regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel J. Summers | 2010-05-03 03:45:56 | Ubuntu 10.04 - Cannot Create TCP/IP Sockets |
Previous Message | Sofer, Yuval | 2010-05-02 07:26:12 | postgres crashes - "not reattach to shared memory " |