Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XoEyE-000306-Go for pgsql-performance@arkaria.postgresql.org; Tue, 11 Nov 2014 17:11:10 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XoEyE-0005h5-0E for pgsql-performance@arkaria.postgresql.org; Tue, 11 Nov 2014 17:11:10 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XoEyC-0005ej-Mk for pgsql-performance@postgresql.org; Tue, 11 Nov 2014 17:11:08 +0000 Received: from 01.zmailcloud.com ([192.198.85.104] helo=mx-out-1.zmailcloud.com) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XoEy9-0002WR-L6 for pgsql-performance@postgresql.org; Tue, 11 Nov 2014 17:11:06 +0000 Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 76E8356481A for ; Tue, 11 Nov 2014 11:11:05 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 687B86019A for ; Tue, 11 Nov 2014 11:11:05 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3KKKyeMYrxs for ; Tue, 11 Nov 2014 11:11:05 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 3E310602A2 for ; Tue, 11 Nov 2014 11:11:05 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 20123602A0 for ; Tue, 11 Nov 2014 11:11:05 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3YWORBjYIRLX for ; Tue, 11 Nov 2014 11:11:05 -0600 (CST) Received: from [192.168.102.93] (74-95-68-173-Spokane.hfc.comcastbusiness.net [74.95.68.173]) by smtp-out-2.01.com (Postfix) with ESMTPSA id B9E5B6019A for ; Tue, 11 Nov 2014 11:11:04 -0600 (CST) Message-ID: <54624327.1070706@agliodbs.com> Date: Tue, 11 Nov 2014 09:11:03 -0800 From: Josh Berkus Organization: PostgreSQL Experts Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: Lock pileup causes server to stall References: <54611702.50308@agliodbs.com> <20141110214000.GL1791@alvin.alvh.no-ip.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) 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 On 11/10/2014 01:40 PM, Alvaro Herrera wrote: > Josh Berkus wrote: >> All, >> >> pg version: 9.3.5 >> RHEL 6.5 >> 128GB/32 cores >> Configured with shared_buffers=16GB >> Java/Tomcat/JDBC application >> >> Server has an issue that whenever we get lock waits (transaction lock >> waits, usually on an FK dependancy) lasting over a minute or more than >> 10 at once, *all* queries on the server slow to a crawl, taking 100X to >> 400X normal execution times. > > Current FK checking makes you wait if the referenced tuple is modified > on any indexed column, not just those that are actually used in > foreign keys. Maybe this case would be sped up if we optimized that. > >> * This applies even to queries which are against other databases, so >> it's not purely a lock blocking issue. > > Oh. Yeah, I think this is more likely a problem with the general lock table and shared_buffers than anything to do with actual lock-blocks. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance