Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 3BE7A632E2F for ; Tue, 14 Apr 2009 04:08:19 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 42154-07 for ; Tue, 14 Apr 2009 04:08:16 -0300 (ADT) Received: from mx3.hub.org (mx3.hub.org [206.223.169.73]) by mail.postgresql.org (Postfix) with ESMTP id 02857632D1B for ; Tue, 14 Apr 2009 04:08:15 -0300 (ADT) X-Greylist: delayed 00:39:22.919014 by SQLgrey-1.7.6 Received: from outA.internet-mail-service.net (outa.internet-mail-service.net [216.240.47.224]) by mx3.hub.org (Postfix) with ESMTP id 5E30837B7C9 for ; Tue, 14 Apr 2009 04:08:15 -0300 (ADT) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id BBF47549A2 for ; Mon, 13 Apr 2009 23:26:03 -0700 (PDT) X-Client-Authorized: MaGic Cook1e Received: from [192.168.1.107] (adsl-71-135-161-147.dsl.pltn13.pacbell.net [71.135.161.147]) by idiom.com (Postfix) with ESMTP id 2D1202D611E for ; Mon, 13 Apr 2009 23:25:48 -0700 (PDT) Message-ID: <49E42C72.9070902@obviously.com> Date: Mon, 13 Apr 2009 23:25:54 -0700 From: Bryce Nesbitt User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: pgsql-sql@postgresql.org Subject: Postgres entering zombie state once a week in production evnvironment Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200904/68 X-Sequence-Number: 32414 We have a medium scale installation of Postgres 8.3 that is freezing about once a week. I'm looking for any hints on how to diagnose the situation, as nothing is logged. The system is matched pair of Sunfire servers, running Debian Etch with a 2.6.18-6-amd64 kernel, PostgreSQL 8.3.4, and DRBD 8.0.13. During a failed state, pg_stat_activity will show hundreds of statements pending. query_start will show the statements arriving at a normal rate (a few per second), but clearly they never complete. The bulk of these statement are a simple select that starts each web session, a statement that generally completes in tenths of milliseconds. Restarting postgres restores normal operation, at the loss of all chance of figuring out what was wrong. postgresql.conf has customized: log_destination = 'syslog' log_min_error_statement = error log_min_duration_statement = 5000 Where can I go from here? I'm turning on log_checkpoints now, though all I see is "postgres[14412]: [4-1] LOG: checkpoint starting: time" with no actual time printed.