From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Marc Rechté <marc4(at)rechte(dot)fr> |
Cc: | pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: OOM killer while pg_restore |
Date: | 2022-03-03 14:46:13 |
Message-ID: | 20220303144613.GF27651@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, Mar 03, 2022 at 09:59:03AM +0100, Marc Rechté wrote:
> Hello,
>
> We have a pg_restore which fails due to RAM over-consumption of the
> corresponding PG backend, which ends-up with OOM killer.
>
> The table has one PK, one index, and 3 FK constraints, active while restoring.
Send the schema for the table, index, and constraints (\d in psql).
What are the server settings ?
https://wiki.postgresql.org/wiki/Server_Configuration
What OS/version ?
> The dump contains over 200M rows for that table and is in custom format,
> which corresponds to 37 GB of total relation size in the original DB.
>
> While importing, one can see the RSS + swap increasing linearly for the
> backend (executing the COPY)
>
> On my machine (quite old PC), it failed after 16 hours, while the disk usage
> was reaching 26 GB and memory usage was 9.1g (RSS+swap)
From | Date | Subject | |
---|---|---|---|
Next Message | ldh@laurent-hasson.com | 2022-03-03 14:55:40 | RE: An I/O error occurred while sending to the backend (PG 13.4) |
Previous Message | Ranier Vilela | 2022-03-03 12:22:09 | Re: OOM killer while pg_restore |