Re: BUG #14606: Memory usage continue to increase

Then I stopped all app instances, the idle postgres processes are gone,
when executed command "/usr/bin/top -bcn 1", the memory usage looks right,
but the result of "docker stats" seems wrong, looks like a docker issue, I
will post this issue to docker forum.

Thanks,
Sam

On Fri, Mar 31, 2017 at 3:39 PM, Sam Dai <sam(dot)dai(at)servicemax(dot)com> wrote:

> Today I tried a performance testing again, after performance testing is
> finished, found memory usage increased about 170MB, then enter the
> Postgresql docker container, executed command "/usr/bin/top -bcn 1", found
> there are some new idle Postgres processes as below, the memory of other
> processed haven't been added, it looks like these new added idle process
> caused the memory usage of Postgresql server is added. Don't know what
> these idle postgres processed for, and they didn't disappear after 2 hours.
>
> 9766 postgres 10 -10 272776 9020 7236 S 0.0 0.0 0:00.00
> postgres: 8wk48fzjxrrkd0hj unpyxldeefjqvm1a 10.0.16.4(39698) idle
>
> 9767 postgres 10 -10 272776 9020 7236 S 0.0 0.0 0:00.00
> postgres: 8wk48fzjxrrkd0hj unpyxldeefjqvm1a 10.0.16.4(39700) idle
>
> ...
>
> 9768 postgres 10 -10 272776 9020 7236 S 0.0 0.0 0:00.00
> postgres: 8wk48fzjxrrkd0hj unpyxldeefjqvm1a 10.0.16.4(39702) idle
>
> 9769 postgres 10 -10 272776 9020 7236 S 0.0 0.0 0:00.00
> postgres: 8wk48fzjxrrkd0hj unpyxldeefjqvm1a 10.0.16.4(39704) idle
>
> On Fri, Mar 31, 2017 at 11:58 AM, Kyotaro HORIGUCHI <
> horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>
>> 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.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/214653D8DF574BFEAA6ED5
>> 3E545E99E4%40maumau
>> https://www.postgresql.org/message-id/20161219.201505.115626
>> 04(dot)horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)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
>>
>>
>