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