Skip site navigation (1) Skip section navigation (2)

Re: How to troubleshoot high mem usage by postgres?

From: Chris <ctlajoie(at)gmail(dot)com>
To: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, pgsql-performance(at)postgresql(dot)org
Subject: Re: How to troubleshoot high mem usage by postgres?
Date: 2010-02-28 01:17:57
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Sat, Feb 27, 2010 at 3:38 PM, Craig Ringer
<craig(at)postnewspapers(dot)com(dot)au> wrote:
> Can you boil this down to a simple PHP test-case that connects to a dummy
> database and repeats something that causes the backend to grow in memory
> usage? Trying to do this - by progressively cutting things out of your test
> until it stops growing - will help you track down what, exactly, is causing
> the growth.

Thank you for your suggestion. I have done this, and in doing so I
have also discovered why this problem is occurring.

My application uses a class that abstracts away the db interaction, so
I do not normally use the pg_* functions directly. Any time any
statement was executed, it created a new "named" prepared statement. I
wrongly assumed that calling pg_free_result() on the statement
resource would free this prepared statement inside of postgres.

I will simply modify the class to use an empty statement name if there
is no need for it to be named (which I actually need very infrequently

I have attached the script I created to test with, for those who are
interested. The first line of the script has the connection string. I
used a db called testdb. run from the command line with:
php -f test3.php

Note my comment in the php file

Thanks for the help everyone.

Attachment: test3.php
Description: application/octet-stream (1.2 KB)

In response to

pgsql-performance by date

Next:From: Ron MayerDate: 2010-02-28 04:05:16
Subject: Re: SSD + RAID
Previous:From: ChrisDate: 2010-02-27 23:25:26
Subject: Re: How to troubleshoot high mem usage by postgres?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group