Re: Autovacuum stopped running - Mailing list pgsql-admin

From Benjamin Krajmalnik
Subject Re: Autovacuum stopped running
Date
Msg-id F4E6A2751A2823418A21D4A160B68988614367@fletch.stackdump.local
Whole thread Raw
In response to Re: Autovacuum stopped running  ("Benjamin Krajmalnik" <kraj@illumen.com>)
Responses Re: Autovacuum stopped running
Re: Autovacuum stopped running
Re: Autovacuum stopped running
List 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@postgresql.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@sss.pgh.pa.us]
> > Sent: Saturday, May 01, 2010 5:10 PM
> > To: Benjamin Krajmalnik
> > Cc: Kevin Grittner; pgsql-admin@postgresql.org
> > Subject: Re: [ADMIN] Autovacuum stopped running
> >
> > "Benjamin Krajmalnik" <kraj@illumen.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

pgsql-admin by date:

Previous
From: "Sofer, Yuval"
Date:
Subject: postgres crashes - "not reattach to shared memory "
Next
From: "Daniel J. Summers"
Date:
Subject: Ubuntu 10.04 - Cannot Create TCP/IP Sockets