Re: BUG #14606: Memory usage continue to increase

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: sam(dot)dai(at)servicemax(dot)com
Cc: michael(dot)paquier(at)gmail(dot)com, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #14606: Memory usage continue to increase
Date: 2017-03-31 03:58:50
Message-ID: 20170331.125850.143008181.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

At Fri, 31 Mar 2017 00:30:31 +0800, Sam Dai <sam(dot)dai(at)servicemax(dot)com> wrote in <CAO+pR0oYSFNgx_oAYxLyNOVmh7R0oG52v3cU0Dq1mkTsQLbqGQ(at)mail(dot)gmail(dot)com>
> Is it possible this issue is caused by the cache or buffer of Postgresql
> server? I guess when we run performance testing, will read/update
> different records, Postgresql might use some new memory for cache or buffer
> some records, and some these cache or buffer will not be cleaned after
> performance test is finished. so the new increased memory is for cache or
> buffer.
> Not sure if my guess is reasonable or not.

Anyway at least the amount of syscache should be revealed on SQL
interface. It is not even managed on builds without defining
CATCACHE_STATS.

For your information, the discussion about syscache bloat is
here.

https://www.postgresql.org/message-id/214653D8DF574BFEAA6ED53E545E99E4%40maumau
https://www.postgresql.org/message-id/20161219.201505.11562604.horiguchi.kyotaro@lab.ntt.co.jp

In breaf, the bloat in the above threads is caused by accesing
many-many nonexistent tables, columns, functions or other SQL
objects. If you did something like that on a long-standing
connection, it is likely to be this issue.

If the "buffer" means shared_buffer, it cannot bloat. I'm not
sure about other kinds of memory leak but I belive there's no
known significant memory leak at present.

> Thanks,
> Sam
>
> On Thu, Mar 30, 2017 at 9:42 PM, Sam Dai <sam(dot)dai(at)servicemax(dot)com> wrote:
>
> > I run Postgresql server in docker container, I run command "docker stats"
> > to measure memory , for example in the below command result, the memory
> > usage of docker container is 1.413 GB.
> >
> > c137012d8af9 793.64% 1.413 GB / 67.55 GB 2.09%
> > 5.927 GB / 7.249 GB 0 B / 10.32 GB 0
> >
> > Thanks,
> >
> > Sam
> >
> >
> >
> > On Thu, Mar 30, 2017 at 9:32 PM, Michael Paquier <
> > michael(dot)paquier(at)gmail(dot)com> wrote:
> >
> >> On Thu, Mar 30, 2017 at 10:24 PM, Sam Dai <sam(dot)dai(at)servicemax(dot)com> wrote:
> >>
> >> (please do not top-post, this breaks the thread logic)
> >>
> >> > My application used ComboPooledDataSource to connect to Postgresql
> >> server,
> >> > the setting is as below, if this issue is syscache bloat, what is the
> >> > solution of this issue?
> >>
> >> Just a question: how are you measuring memory?
> >>
> >> > <property name="maxConnectionAge" value="300" /> <!-- 5 min -->
> >> > <property name="maxIdleTime" value="180" /> <!-- 3 min -->
> >>
> >> Seeing that, likely this is not syscache.

I agree with you. It's unlikely to happen in such a short time.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2017-03-31 05:05:13 Re: [BUGS] Bug in Physical Replication Slots (at least 9.5)?
Previous Message Venkata B Nagothi 2017-03-31 02:40:00 Re: Bug in Physical Replication Slots (at least 9.5)?