Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84) (envelope-from ) id 1adcSr-0006j6-Lk for pgsql-performance@arkaria.postgresql.org; Wed, 09 Mar 2016 11:39:41 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1adcSr-0002jz-3H for pgsql-performance@arkaria.postgresql.org; Wed, 09 Mar 2016 11:39:41 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1adcRB-0000hL-1k for pgsql-performance@postgresql.org; Wed, 09 Mar 2016 11:37:57 +0000 Received: from mail-wm0-x22b.google.com ([2a00:1450:400c:c09::22b]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1adcR5-0002Au-Jg for pgsql-performance@postgresql.org; Wed, 09 Mar 2016 11:37:55 +0000 Received: by mail-wm0-x22b.google.com with SMTP id l68so188514512wml.0 for ; Wed, 09 Mar 2016 03:37:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=xJkmp/t7YvgGeaB5TcAaF/1aS62dAQv354P6Cd2M5rU=; b=PgwSYN7PJQV1Wh7B66O1gFd7OzgMAi9BnM//1AOiQCrCDOQ/zwY0yIOKWdZnDLnpuI ij8nSsSFII8ZzoV9zwM+SxFglTLY5ZAYbBJ0O0aNhfHxpQxSU4mFX6DuFDuesrzx927e QtTdnVBDS+QT6jDzxGjYzGZEOIDq4I5SOy33SOf0J1ywTltGUs1jOopoE0+tQ+CpUp0I y5f0MBOAlsDmF8taeYLZOMJ1BXdHBwW94tDBVoWwVC3M/HVSoAagVw/8Ht7yyAX624kD 9SlZYeQXWDKHbsHNZW83j1u66ZJ0aXdITXZRSVKuq9HTSpKfO00p+iwTrPJJ1LEWcNXz wfdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=xJkmp/t7YvgGeaB5TcAaF/1aS62dAQv354P6Cd2M5rU=; b=l8r/rLFSW86vYHMOObRog8V5fVNYyQ4YgbgxGOkm1U0MqjSxPymyD1LTRJrhy7dqJz EIO8/BfsEjMZSzRkkAuC9QEG/+FoQm5zYNTf1UZtEkj9fJLt68YD/IKavatV/C8h6T53 +2a0zbvsfuH8ChHlol4dtSlYmLlSmOMtTSm36AClYn6wZB7JBCUP8eelZwTC59EWp3es dcKtSF7jTCjZeOU+7KSc5WOfvewHHH/rLe5PEEJqnl+zO5i6CvmMpvL/Zo2uRWBinkIm TD1ikpZpC+yV4KQFvRt3jIn6zBObtUDl82kYbR+OR19rPzGKxO08cQZi9tFRhoWx9O2B aN2g== X-Gm-Message-State: AD7BkJLK1Qgz9pGts6eM8MsS4TJl+0kETLVoF8lLvHUnty6Wrcl4q/pS6/6i09M5sRxyN40A X-Received: by 10.28.148.142 with SMTP id w136mr8918694wmd.90.1457523469398; Wed, 09 Mar 2016 03:37:49 -0800 (PST) Received: from development (ip-78-45-216-26.net.upcbroadband.cz. [78.45.216.26]) by smtp.gmail.com with ESMTPSA id lh1sm7462966wjb.20.2016.03.09.03.37.48 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Mar 2016 03:37:48 -0800 (PST) Message-ID: <1457523467.24545.43.camel@2ndquadrant.com> Subject: Re: using stale statistics instead of current ones because stats collector is not responding From: Tomas Vondra To: Tory M Blue Cc: pgsql-performance Date: Wed, 09 Mar 2016 12:37:47 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 (3.12.11-1.fc21) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org 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 (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance