Search Postgresql Archives

Re: PostgreSQL 14.4 ERROR: out of memory issues

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





po 18. 7. 2022 v 20:26 odesílatel Aleš Zelený <zeleny.ales@xxxxxxxxx> napsal:

po 18. 7. 2022 v 16:25 odesílatel Tom Lane <tgl@xxxxxxxxxxxxx> napsal:
=?UTF-8?B?QWxlxaEgWmVsZW7DvQ==?= <zeleny.ales@xxxxxxxxx> 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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux