WARNING: pgstat wait timeout
in [PgSql]
|
From: Greg Smith on 29 Jan 2010 02:45 I just found a few of these errors in a log file during some pgbench testing tonight. Linux, recent CVS HEAD; given the range of systems and versions this has been reported against now, this bug doesn't look like a platform or version/build specific issue. Unfortunately the instance I had up wasn't setup very well for logging, but I did notice that all of the ones I saw had nearby messages about autovacuum issues, which seems to match Tom's earlier suggestion at http://archives.postgresql.org/pgsql-bugs/2009-07/msg00083.php that the source of the warning (but not necessarily the underlying problem) for these is the autovacuum launcher complaining; here's two different sets: ERROR: canceling autovacuum task CONTEXT: automatic analyze of table "pgbench.public.pgbench_accounts" WARNING: pgstat wait timeout WARNING: pgstat wait timeout ERROR: canceling autovacuum task CONTEXT: automatic analyze of table "pgbench.public.pgbench_accounts" WARNING: pgstat wait timeout ERROR: canceling autovacuum task CONTEXT: automatic analyze of table "pgbench.public.pgbench_accounts" ERROR: canceling autovacuum task CONTEXT: automatic analyze of table "pgbench.public.pgbench_accounts" Because of what I'm (not) seeing in pg_stat_bgwriter, I'm suspicious that its underlying work or messages may be involved here. I'm not seeing the sort of totals I expect in that view after these large bouts of activity. Now, my use tonight has included the new pg_stat_reset_shared('bgwriter') to clear out those stats between runs, so perhaps that's involved too. Guessing not only because of the reports going back to 8.4 that also have this error message. Will keep an eye out for this one now that I know I might run into it, have already cranked up the logging and will look for something reproducible to gather more info. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg(a)2ndQuadrant.com www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Magnus Hagander on 29 Jan 2010 08:16 2010/1/29 Greg Smith <greg(a)2ndquadrant.com>: > I just found a few of these errors in a log file during some pgbench testing tonight. Linux, recent CVS HEAD; given the range of systems and versions this has been reported against now, this bug doesn't look like a platform or version/build specific issue. > > Unfortunately the instance I had up wasn't setup very well for logging, but I did notice that all of the ones I saw had nearby messages about autovacuum issues, which seems to match Tom's earlier suggestion at http://archives.postgresql.org/pgsql-bugs/2009-07/msg00083.php that the source of the warning (but not necessarily the underlying problem) for these is the autovacuum launcher complaining; here's two different sets: > > ERROR: canceling autovacuum task > CONTEXT: automatic analyze of table "pgbench.public.pgbench_accounts" > WARNING: pgstat wait timeout > WARNING: pgstat wait timeout > ERROR: canceling autovacuum task > CONTEXT: automatic analyze of table "pgbench.public.pgbench_accounts" > > WARNING: pgstat wait timeout > ERROR: canceling autovacuum task > CONTEXT: automatic analyze of table "pgbench.public.pgbench_accounts" > ERROR: canceling autovacuum task > CONTEXT: automatic analyze of table "pgbench.public.pgbench_accounts" > > Because of what I'm (not) seeing in pg_stat_bgwriter, I'm suspicious that its underlying work or messages may be involved here. I'm not seeing the sort of totals I expect in that view after these large bouts of activity. Now, my use tonight has included the new pg_stat_reset_shared('bgwriter') to clear out those stats between runs, so perhaps that's involved too. Guessing not only because of the reports going back to 8.4 that also have this error message. > > Will keep an eye out for this one now that I know I might run into it, have already cranked up the logging and will look for something reproducible to gather more info. I've seen this happen semi-frequently during initdb on win32 on an Amazon EC2 image. I attributed it to the combination of windows and overloaded virtualization, but it may just be that it shows up more often there. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Pages: 1 Prev: 64-bit size pgbench Next: [HACKERS] [CFReview] Red-Black Tree |