Re: PostgreSQL 14.4 ERROR: out of memory issues

po 18. 7. 2022 v 20:26 odesílatel Aleš Zelený <zeleny(dot)ales(at)gmail(dot)com>
napsal:

>
> 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.
>>
>
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;

Cannot be some memory lost in this allocation?

Regards

Pavel

>
>> regards, tom lane
>>
>
> Kind regards
> Ales Zeleny
>