Re: BUG #12183: Memory leak in long running sessions

From: Kevin Grittner <kgrittn(at)ymail(dot)com>
To: Valentine Gogichashvili <valgog(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #12183: Memory leak in long running sessions
Date: 2014-12-10 16:19:12
Message-ID: 1497380283.4859013.1418228352955.JavaMail.yahoo@jws100205.mail.ne1.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Valentine Gogichashvili <valgog(at)gmail(dot)com> wrote:

> Can we collect some more information that would give more hints
> on what is going on there?

As Tom already said, a reproducible test case (i.e., a script which
a developer can run starting from an empty database) which
demonstrates the problem would be ideal. If you can't produce
that, install smem (if it's not already installed) and run this at
intervals (beginning, middle, and end would probably suffice):

smem -trs uss

The other thing that would give valuable information would be to
set overcommit_memory to 2 and overcommit_ratio to something like
80. If there is a memory leak in PostgreSQL, it will probably dump
a memory map when an allocation attempt fails. It would also be
great if you could enable core dumps for postgres and get a
backtrace from the point of failure in this configuration.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrew Sackville-West 2014-12-10 16:29:55 Re: regression, deadlock in high frequency single-row UPDATE
Previous Message wangzhipengkmust 2014-12-10 15:55:29 BUG #12187: Cant find the postgresql-client installation by yum install