public inbox for [email protected]
help / color / mirror / Atom feedusing stale statistics instead of current ones because stats collector is not responding
2+ messages / 2 participants
[nested] [flat]
* using stale statistics instead of current ones because stats collector is not responding
@ 2016-03-09 00:18 Tory M Blue <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Tory M Blue @ 2016-03-09 00:18 UTC (permalink / raw)
To: pgsql-performance
No hits on the intratubes on this.
Any idea ? We are doing some massive deletes so was curious as to what
would cause this error. The DB is up, not overburdened, just some big
deletes and slon replication processes.
CentOS 6.6
Postgres 9.4.5
First time I've ever seen this alert/error just curious about it.
2016-03-08 16:17:29 PST 11877 2016-03-08 16:17:29.850 PSTLOG: using
stale statistics instead of current ones because stats collector is not
responding
Thanks
Tory
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: using stale statistics instead of current ones because stats collector is not responding
@ 2016-03-09 11:37 Tomas Vondra <[email protected]>
parent: Tory M Blue <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Tomas Vondra @ 2016-03-09 11:37 UTC (permalink / raw)
To: Tory M Blue <[email protected]>; +Cc: pgsql-performance
Hi,
On Tue, 2016-03-08 at 16:18 -0800, Tory M Blue wrote:
> No hits on the intratubes on this.
>
>
> Any idea ? We are doing some massive deletes so was curious as to what
> would cause this error. The DB is up, not overburdened, just some big
> deletes and slon replication processes.
>
> CentOS 6.6
> Postgres 9.4.5
>
> First time I've ever seen this alert/error just curious about it.
>
> 2016-03-08 16:17:29 PST 11877 2016-03-08 16:17:29.850 PSTLOG:
> using stale statistics instead of current ones because stats collector
> is not responding
PostgreSQL tracks 'runtime statistics' (number of scans of a table,
tuples fetched from index/table etc.) in a file, maintained by a
separate process (collector). When a backed process requests some of the
stats (e.g. when a monitoring tool selects from pg_stat_all_tables) it
requests a recent snapshot of the file from the collector.
The log message you see means that the collector did not handle such
requests fast enough, and the backend decided to read an older snapshot
instead. So you may see some stale data in monitoring for example.
This may easily happen if the I/O system is overloaded, for example. The
simplest solution is to move the statistics file to RAM disk (e.g. tmpfs
mount on Linux) using stats_temp_directory in postgresql.conf.
The space neede depends on the number of objects (databases, tables,
indexes), and usually it's a megabyte in total or so.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-performance mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2016-03-09 11:37 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2016-03-09 00:18 using stale statistics instead of current ones because stats collector is not responding Tory M Blue <[email protected]>
2016-03-09 11:37 ` Tomas Vondra <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox