Re: One PG process eating more than 40GB of RAM and getting killed by OOM

Поиск
Список
Период
Сортировка
От Jean-Christophe Boggio
Тема Re: One PG process eating more than 40GB of RAM and getting killed by OOM
Дата
Msg-id 416d1607-4650-4624-b8e5-46f8a674aebf@thefreecat.org
обсуждение исходный текст
Ответ на Re: One PG process eating more than 40GB of RAM and getting killed by OOM  (Jeff Janes <jeff.janes@gmail.com>)
Ответы Re: One PG process eating more than 40GB of RAM and getting killed by OOM  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: One PG process eating more than 40GB of RAM and getting killed by OOM  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-admin
Le 13/10/2023 à 18:48, Jeff Janes a écrit :
> Yes, turning off overcommit doesn't play with graphical environments, 
> in my experience. But a production database probably shouldn't be 
> running on a system like that. On non-prod systems, you can either 
> turn it off temporarily, or you could try to catch the problem before 
> it becomes fatal and get the log with pg_log_backend_memory_contexts.

As I said, this is my dev laptop and no, I would never waste precious 
RAM this way on a production server ;-)

>  We can see what the problem is (over 137,000 concurrent tuple sorts), 
> but we can't tell what is ultimately causing it.  You will need to dig 
> into, or disclose, the contents of the procedure.

I have no problem disclosing this code and data to the PG dev team (this 
is client data though so please keep it for yourselves). Where can I 
send you a link to the dump ?

Best,

JC




В списке pgsql-admin по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: One PG process eating more than 40GB of RAM and getting killed by OOM
Следующее
От: Tom Lane
Дата:
Сообщение: Re: One PG process eating more than 40GB of RAM and getting killed by OOM