Re: PostgreSQL 14.4 ERROR: out of memory issues

From: Aleš Zelený <zeleny(dot)ales(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: PostgreSQL 14.4 ERROR: out of memory issues
Date: 2022-07-18 18:26:21
Message-ID: CAODqTUbB+Vt0o2kv5pvNH1XpmWf6NQR2nnkPNvjOVd17Ts6z_w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

po 18. 7. 2022 v 16:25 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> =?UTF-8?B?QWxlxaEgWmVsZW7DvQ==?= <zeleny(dot)ales(at)gmail(dot)com> writes:
> > after some time, I've found a process consuming over 1GB of memory"
> > -bash-4.2$ grep RssAnon /proc/*/status | sort -nk2 | tail
> > /proc/17048/status:RssAnon: 1053952 kB
>
> > Here are memory contexts for PID 17048:
>
> > TopMemoryContext: 422592 total in 14 blocks; 42536 free (169 chunks);
> > 380056 used
> ...
> > Grand total: 14312808 bytes in 4752 blocks; 3920880 free (1043 chunks);
> > 10391928 used
>
> OK, so PG's normal memory consumption is only ~14MB. Where'd the
> rest of it go?
>
> > -bash-4.2$ pmap 17048
> ...
> > 0000000002d93000 838092K rw--- [ anon ]
> > 00007fd999777000 180232K rw--- [ anon ]
> > 00007fd9a8d75000 32772K rw--- [ anon ]
>

and a few hours later it even grew:

-bash-4.2$ cat 20220718_200230.pmap.17048.log | grep anon
0000000000db3000 200K rw--- [ anon ]
0000000002d15000 504K rw--- [ anon ]
0000000002d93000 934476K rw--- [ anon ]
00007fd989776000 311304K rw--- [ anon ]
00007fd9a8d75000 32772K rw--- [ anon ]
00007fd9acb65000 20K rw--- [ anon ]
00007fd9affc1000 372K rw--- [ anon ]

From previous observation I know, that the process RssAnon memory grew over
time, sometimes there are some steps. Still, generally, the growth is
linear until the process finishes or we run out of memory, and the cluster
is reinitialized by the postmaster.
No such behavior on older versions until 14.3 (including).

...
> Probably the 838M chunk is shared memory? Is that within hailing
> distance of your shared_buffers setting?
>

postgres=# show shared_buffers ;
shared_buffers
----------------
10GB
(1 row)

...
> > 00007fd9b0551000 10827040K rw-s- zero (deleted)
>

These 10GB matches 10GB configured as shared buffers.

> ...
> And here we have the culprit, evidently ... but what the dickens
> is it? I can't think of any mechanism within Postgres that would
> create such an allocation.
>
> regards, tom lane
>

Kind regards
Ales Zeleny

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Marc Millas 2022-07-18 18:48:15 Re: postgis
Previous Message Adrian Klaver 2022-07-18 17:14:59 Re: postgis