From: | Guillaume Lelarge <guillaume(at)lelarge(dot)info> |
---|---|
To: | PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Lots of memory allocated when reassigning Large Objects |
Date: | 2021-11-29 12:49:24 |
Message-ID: | CAECtzeW2DAoioEGBRjR=CzHP6TdL=yosGku8qZxfX9hhtrBB0Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
One of our customers had a very bad issue while trying to reassign objects
from user A to user B. He had a lot of them, and the backend got very
hungry for memory. It finally all went down when the linux kernel decided
to kill the backend (-9 of course).
I attach three shell scripts showing the issue. create.sh creates a
database and two users. Then it imports a million Large Objects in this new
database. There's no drop.sh as it is a simple "dropdb foodb".
session1_monitor.sh will start logging memory usage in the server log file
every second. So it needs v14, but our customer is in v11. While this
script runs, you can start session2_reindex.sh. This script will only run a
reassign from one user to another.
Here is what I get in the server log file:
$ grep "Grand total" 14.log
LOG: Grand total: 15560832 bytes...
LOG: Grand total: 68710528 bytes...
LOG: Grand total: 119976064 bytes..
LOG: Grand total: 171626624 bytes...
LOG: Grand total: 224211072 bytes...
LOG: Grand total: 276615296 bytes...
LOG: Grand total: 325611648 bytes...
LOG: Grand total: 378196096 bytes...
LOG: Grand total: 429838464 bytes...
LOG: Grand total: 481104000 bytes...
IOW, it's asking for at least 481MB to reassign 1 million empty LO. It
strikes me as odd.
FWIW, the biggest memory context is this one:
LOG: level: 2; PortalContext: 479963904 total in 58590 blocks; 2662328
free (32567 chunks); 477301576 used: <unnamed>
Memory is released at the end of the reassignment. So it's definitely not
leaked forever, but only during the operation, which looks like a missing
pfree (or something related). I've tried to find something like that in the
code somewhere, but to no avail. I'm pretty sure I missed something, which
is the reason for this email :)
Thanks.
Regards.
PS : we've found a workaround to make it work for our customer (executing
all the required ALTER LARGE OBJECT ... OWNER TO ...), but I'm still amazed
by this weird behaviour.
--
Guillaume.
Attachment | Content-Type | Size |
---|---|---|
create.sh | application/x-shellscript | 292 bytes |
session2_reindex.sh | application/x-shellscript | 122 bytes |
session1_monitor.sh | application/x-shellscript | 274 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Arne Roland | 2021-11-29 14:01:35 | Re: Enforce work_mem per worker |
Previous Message | Marcos Pegoraro | 2021-11-29 12:49:21 | Re: pg_upgrade and publication/subscription problem |