pg_stat: last vacuum and analyze times are not being updated - v8.3.5

pg_stat: last vacuum and analyze times are not being updated - v8.3.5

am 23.03.2010 12:03:40 von Steve Jones

This is a multi-part message in MIME format.

------_=_NextPart_001_01CACA78.7F51811F
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

PostgreSQL Version: 8.3.5

OS Version: FreeBSD 7.0 i386

=20

Issue: the last_vacuum column is not
being updated following a manual vacuum against a table or database.
This was highlighted recently when I configured the check_postgresql.pl
script to be used from NAGIOS. =20

=20

Background:

Drilling down through the pg_stat_all_tables view, the underlying
functions=20

=20

* pg_stat_get_last_vacuum_time(),=20

* pg_stat_get_last_autovacuum_time(),=20

* pg_stat_get_last_analyze_time() and

* pg_stat_get_last_autoanalyze_time()

=20

are not returning anything even though I have run manual and auto
vacuums against these tables recently, along with ANALYZE.

=20

Whether it makes a difference, I can confirm that track_counts and
track_activities are both on in postgresql.conf. The stats collection
service is also running on the server - I've verified this by looking at
the processes on the server.

=20

This is causing issues with both our monitoring and also our confidence
that the autovacuum service is running as it should. We have a standby
server with identical configuration (as far as I can see) and this is
correctly keeping the stats up to date. The only difference is postgres
has been running well over a year on the server with the issue.

=20

Many thanks in advance,

=20

Steve Jones

=20


------_=_NextPart_001_01CACA78.7F51811F
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"> http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii"> (filtered medium)"> vlink=3Dpurple>

PostgreSQL =
Version:       8.3.5

class=3DMsoNormal>OS Version:        =
            &=
nbsp;   FreeBSD 7.0 i386

class=3DMsoNormal> 

style=3D'margin-left:108.0pt;text-indent:-108.0pt'>Issue: =
            &=
nbsp;           &n=
bsp;          the =
last_vacuum column is not being updated following a manual vacuum =
against a table or database.  This was highlighted recently when I =
configured the check_postgresql.pl script to be used from NAGIOS.  =

 

class=3DMsoNormal>Background:

class=3DMsoNormal>Drilling down through the pg_stat_all_tables view, the =
underlying functions

class=3DMsoNormal> 

style=3D'text-indent:-18.0pt;mso-list:l0 level1 lfo1'> !supportLists]> style=3D'mso-list:Ignore'>· Roman"'>         =
pg_stat_get_last_vacuum_time(), =

style=3D'text-indent:-18.0pt;mso-list:l0 level1 lfo1'> !supportLists]> style=3D'mso-list:Ignore'>· Roman"'>         =
pg_stat_get_last_autovacuum_time(), =

style=3D'text-indent:-18.0pt;mso-list:l0 level1 lfo1'> !supportLists]> style=3D'mso-list:Ignore'>· Roman"'>         =
pg_stat_get_last_analyze_time() =
and

style=3D'text-indent:-18.0pt;mso-list:l0 level1 lfo1'> !supportLists]> style=3D'mso-list:Ignore'>· Roman"'>         =
pg_stat_get_last_autoanalyze_time() o:p>

 

class=3DMsoNormal>are not returning anything even though I have run =
manual and auto vacuums against these tables recently, along with =
ANALYZE.

 

class=3DMsoNormal>Whether it makes a difference, I can confirm that =
track_counts and track_activities are both on in postgresql.conf. =
  The stats collection service is also running on the server =
– I’ve verified this by looking at the processes on the =
server.

 

class=3DMsoNormal>This is causing issues with both our monitoring and =
also our confidence that the autovacuum service is running as it =
should.  We have a standby server with identical configuration (as =
far as I can see) and this is correctly keeping the stats up to =
date.  The only difference is postgres has been running well over a =
year on the server with the issue.

class=3DMsoNormal> 

Many thanks =
in advance,

class=3DMsoNormal> 

style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"; mso-fareast-l=
anguage:EN-GB'>Steve Jones

class=3DMsoNormal> 


------_=_NextPart_001_01CACA78.7F51811F--

Re: pg_stat: last vacuum and analyze times are not being updated - v8.3.5

am 23.03.2010 16:43:32 von Tom Lane

"Steve Jones" writes:
> Issue: the last_vacuum column is not
> being updated following a manual vacuum against a table or database.

It works for me in 8.3 ... as long as there already is a stats entry for
the table in question. You may be running into the pre-9.0 behavior
that the vacuum time update gets thrown away if there is no pre-existing
stats entry. If you vacuum twice, does the time of the second vacuum
show up?

http://archives.postgresql.org/pgsql-committers/2009-09/msg0 0062.php

regards, tom lane

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: pg_stat: last vacuum and analyze times are not being updated - v8.3.5

am 25.03.2010 17:01:37 von Tom Lane

[ re-including the mailing list ]

"Steve Jones" writes:
> For your information, this is what I did last night.

> Restarted the stats collector process, by issuing a kill -9 against it.
> As you said, postgres started up a new collector process immediately. I
> tried a few vacuums and the stats still weren't being updated.

> I then restarted postgres in the hope this would help. It didn't.

> I finally had to reboot the whole server which fixed the problem. As
> you said, I have to run two manual vacuums before the stats are showing
> up. This possible points a finger towards FreeBSD now? Would
> appreciate your thoughts.

If restarting Postgres didn't fix it then the problem has to have been
at the operating system level. I can hardly think what the problem
would have been exactly. It's not hard to imagine something going
wrong in the kernel state for the UDP socket we use to send messages to
the stats collector process; but restarting Postgres should have torn
down that socket and created a new one. Perhaps something wrong in
global state for all local UDP transfers? I dunno. But it seems like
time to call in some FreeBSD hackers.

regards, tom lane

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin