Received: from localhost (unknown [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 8C3012E00BA for ; Thu, 3 Jan 2008 12:35:06 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 34620-02 for ; Thu, 3 Jan 2008 12:35:03 -0400 (AST) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 79EF52E3521 for ; Thu, 3 Jan 2008 12:35:03 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.1/8.14.1) with ESMTP id m03GZ1FK006664; Thu, 3 Jan 2008 11:35:01 -0500 (EST) To: "Peter Childs" cc: "Postgresql Performance" Subject: Re: Commit takes a long time. In-reply-to: References: Comments: In-reply-to "Peter Childs" message dated "Thu, 03 Jan 2008 14:35:37 +0000" Date: Thu, 03 Jan 2008 11:35:01 -0500 Message-ID: <6663.1199378101@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200801/6 X-Sequence-Number: 28245 "Peter Childs" writes: > Using Postgresql 8.1.10 every so often I get a transaction that takes a > while to commit. > I log everything that takes over 500ms and quite reguallly it says things > like > 707.036 ms statement: COMMIT AFAIK there are only two likely explanations for that: 1. You have a lot of deferred triggers that have to run at COMMIT time. 2. The disk system gets so bottlenecked that fsync'ing the commit record takes a long time. If it's #2 you could probably correlate the problem with spikes in I/O activity as seen in iostat or vmstat. If it is a disk usage spike then I would make the further guess that what causes it might be a Postgres checkpoint. You might be able to dampen the spike a bit by playing with the checkpoint parameters, but the only real fix will be 8.3's spread-out-checkpoints feature. regards, tom lane