X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id B4C54529AA for ; Wed, 29 Jun 2005 12:08:43 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 80210-09 for ; Wed, 29 Jun 2005 15:08:36 +0000 (GMT) Received: from mail.baymountain.com (mail.baymountain.com [8.7.96.19]) by svr1.postgresql.org (Postfix) with SMTP id 2B00D5295A for ; Wed, 29 Jun 2005 12:08:35 -0300 (ADT) Received: (qmail 10591 invoked by uid 504); 29 Jun 2005 15:08:33 -0000 Received: from emil@baymountain.com by mail.baymountain.com by uid 501 with qmail-scanner-1.16 (spamassassin: 2.53. Clear:SA:0(0.0/7.0):. Processed in 0.272865 secs); 29 Jun 2005 15:08:33 -0000 Received: from unknown (HELO briggspack.com) (emil@briggspack.com@24.211.148.77) by mail.baymountain.com with SMTP; 29 Jun 2005 15:08:32 -0000 From: Emil Briggs Reply-To: emil@baymountain.com Organization: Baymountain, Inc. To: pgsql-performance@postgresql.org Subject: Exclusive lock question Date: Wed, 29 Jun 2005 11:08:28 -0400 User-Agent: KMail/1.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506291108.28516.emil@baymountain.com> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.05 tagged_above=0 required=5 tests=FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200506/588 X-Sequence-Number: 13225 I have been trying to diagnose a performance problem we have been seeing with a postgres application. The performance of the database server is usually quite good but every now and then it slows to a crawl. The output of vmstat does not show excessive CPU usage or disk IO. The output of ps does show that the number of postgres process's that appear to be stuck in some query spikes and in some cases restarting the postgres server is the only way to clear them. While trying to diagnose this problem I ran select * from pg_locks I could understand most of the output but I was wondering what a result like the following indicates relation | database | transaction | pid | mode | granted ----------+----------+-------------+-------+---------------+--------- | | 26052434 | 29411 | ExclusiveLock | t | | 26051641 | 29345 | ExclusiveLock | t | | 26052415 | 29519 | ExclusiveLock | t | | 26052407 | 29381 | ExclusiveLock | t | | 26052432 | 29658 | ExclusiveLock | t When I see the slowdowns there are hundreds of these with no entry for relation or database. Any ideas what is being locked in this case? Emil