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
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 |