Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id EF053632314 for ; Sat, 27 Feb 2010 18:39:46 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 37382-10 for ; Sat, 27 Feb 2010 22:39:31 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 4779F632568 for ; Sat, 27 Feb 2010 18:39:36 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id o1RMdXLZ018570; Sat, 27 Feb 2010 17:39:34 -0500 (EST) To: Chris cc: pgsql-performance@postgresql.org Subject: Re: How to troubleshoot high mem usage by postgres? In-reply-to: <57033cf81002271429wb0da13am37b3cb6258103ea5@mail.gmail.com> References: <57033cf81002271429wb0da13am37b3cb6258103ea5@mail.gmail.com> Comments: In-reply-to Chris message dated "Sat, 27 Feb 2010 15:29:13 -0700" Date: Sat, 27 Feb 2010 17:39:33 -0500 Message-ID: <18568.1267310373@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.462 tagged_above=-10 required=5 tests=AWL=0.137, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201002/393 X-Sequence-Number: 37814 Chris writes: > Hi, I'm having an issue where a postgres process is taking too much > memory when performing many consecutive inserts and updates from a PHP > script (running on the command line). I would like to know what sort > of logging I can turn on to help me determine what is causing memory > to be consumed and not released. Are you doing all these inserts/updates within a single transaction? If so, I think the odds are very good that what's eating the memory is the list of pending trigger actions, resulting from either user-created triggers or foreign-key check triggers. The best way of limiting the problem is to commit more often. If you want to try to confirm that, what I would do is run the postmaster under a more restrictive ulimit setting, so that it runs out of memory sometime before the system starts to swap. When it does run out of memory, you'll get a memory context map printed to postmaster stderr, and that will show which context is eating all the memory. If it's "AfterTriggerEvents" then my guess above is correct --- otherwise post the map for inspection. regards, tom lane