Re: PostgreSQL 14.4 ERROR: out of memory issues - Mailing list pgsql-general
| From | Pavel Stehule |
|---|---|
| Subject | Re: PostgreSQL 14.4 ERROR: out of memory issues |
| Date | |
| Msg-id | CAFj8pRD55Wbb+uQ-obey0D8ENXM1wkdxFrA2Nhup=+KZFGTJsQ@mail.gmail.com Whole thread Raw |
| In response to | Re: PostgreSQL 14.4 ERROR: out of memory issues (Aleš Zelený <zeleny.ales@gmail.com>) |
| List | pgsql-general |
po 18. 7. 2022 v 20:26 odesílatel Aleš Zelený <zeleny.ales@gmail.com> napsal:
po 18. 7. 2022 v 16:25 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:Aleš Zelený <zeleny.ales@gmail.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.
I checked code, and there is lot of usage of malloc function.
static void *
GenerationAlloc(MemoryContext context, Size size)
{
<-->GenerationContext *set = (GenerationContext *) context;
<-->GenerationBlock *block;
<-->GenerationChunk *chunk;
<-->Size<--><-->chunk_size = MAXALIGN(size);
<-->Size<--><-->required_size = chunk_size + Generation_CHUNKHDRSZ;
<-->/* is it an over-sized chunk? if yes, allocate special block */
<-->if (chunk_size > set->allocChunkLimit)
<-->{
<--><-->Size<--><-->blksize = required_size + Generation_BLOCKHDRSZ;
<--><-->block = (GenerationBlock *) malloc(blksize);
<--><-->if (block == NULL)
<--><--><-->return NULL;
GenerationAlloc(MemoryContext context, Size size)
{
<-->GenerationContext *set = (GenerationContext *) context;
<-->GenerationBlock *block;
<-->GenerationChunk *chunk;
<-->Size<--><-->chunk_size = MAXALIGN(size);
<-->Size<--><-->required_size = chunk_size + Generation_CHUNKHDRSZ;
<-->/* is it an over-sized chunk? if yes, allocate special block */
<-->if (chunk_size > set->allocChunkLimit)
<-->{
<--><-->Size<--><-->blksize = required_size + Generation_BLOCKHDRSZ;
<--><-->block = (GenerationBlock *) malloc(blksize);
<--><-->if (block == NULL)
<--><--><-->return NULL;
Cannot be some memory lost in this allocation?
Regards
Pavel
regards, tom laneKind regardsAles Zeleny
pgsql-general by date: