Hello,
No, I do not think there are gdb symbols in the docker images. So far
I tried to set vm.overcommit_memory to 2 so that postgres received an
error while allocating memory, but it was too stressful on the
production and it received the error much earlier, when it was using
little memory yet. So I do not think it shows some relevant
information, but anyway logs are attached.
I have also made several database migrations (dump/restore). 13-alpine
-> 12-alpine -> 12 -> 10. All variants except version 10 were "eating"
memory. Today I also migrated to version 11 and it also looks well. I
do not want to experiment on production further, so I am thinking if
there is some sort of postgres proxy to mirror queries to a test
database, or to save and replay them. So that I could continue testing
aside from the production service.
On Wed, Oct 7, 2020 at 7:06 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> > I migrated a database from postgresql 10.14 in a container to
> > postgres:13-alpine in docker. After a migration I see that postgresql
> > processes alltogether eat memory without limits until OOM comes.
>
> Not much to go on here. If you have debug symbols available, maybe
> you could attach gdb to one of the bloated processes and do
>
> call MemoryContextStats(TopMemoryContext)
>
> which'd produce a memory usage report on the server's stderr.
>
> Another idea is to start the server under a smaller ulimit,
> in hopes of getting ENOMEM failures before reaching the point
> of triggering OOM kills. That would also result in memory
> usage reports, so you could get one even if it's a non-debug
> build.
>
> Otherwise, we'll have to ask for a reproducible test case ...
>
> regards, tom lane
