pg.ddx.io  pgsql-admin@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Ron <ronljohnsonjr@gmail.com>
To: pgsql-admin@lists.postgresql.org
Subject: Re: 13.4 on RDS, SSL SYSCALL EOF on restore
Date: Sun, 10 Oct 2021 01:10:23 -0500
Message-ID: <07ed72a9-52dc-2c26-596e-7e80315ceb11@gmail.com> (raw)
In-Reply-To: <CAOC+FBV2+mp-BJZfkjPaQCs_vf3UGpS8Z+N8mBj3i4SiZf1KWQ@mail.gmail.com>
References: <202110082245.4wq5lie5euyx@alvherre.pgsql>
	<202110082248.xmzxkwo5gup7@alvherre.pgsql>
	<CAOC+FBV2+mp-BJZfkjPaQCs_vf3UGpS8Z+N8mBj3i4SiZf1KWQ@mail.gmail.com>

What if you use a bigger instance (and maybe provisioned IO, too) just for 
the time it takes to restore the database, and then modify it down to a 
"production sized" instance?

On 10/9/21 1:20 PM, Wells Oliver wrote:
> Thanks all. Reducing maintenance_work_mem to 1GB and keeping 
> shared_buffers at 4GB did allow the restore to complete. It took ~770m 
> with 16 processes and that configuration, but only ~500m with 
> maintenance_work_mem at 2GB, shared_buffers at 4GB, and 8 processes. Of 
> course, with maintenance_work_mem at 2GB and 16 processes, we ran out of 
> memory and kaboom.
>
> If anyone has any more parameter values I should try to improve on that 
> restore time, I'd love to hear them.
>
> Thanks for the help here.
>
>
> On Fri, Oct 8, 2021 at 3:48 PM Alvaro Herrera <alvherre@alvh.no-ip.org 
> <mailto:alvherre@alvh.no-ip.org>> wrote:
>
>     On 2021-Oct-08, Alvaro Herrera wrote:
>
>     > On 2021-Oct-08, Wells Oliver wrote:
>     >
>     > > Dug out some more logging:
>     >
>     > > 2021-10-08 20:35:08 UTC::@:[12682]:LOG:  server process (PID 3970)
>     was terminated by signal 9: Killed
>     > > 2021-10-08 20:35:08 UTC::@:[12682]:DETAIL:  Failed process was
>     running: CREATE INDEX ...
>     >
>     > So what's happening here is that the instance is running out of RAM
>     > while creating some index, and the kernel is killing the process.  I
>     > would probably blame the combination of shared_buffers=4GB with
>     > maintenance_work_mem=2GB, together with the instance's total RAM.
>
>     Also, maybe RDS could be smarter about this situation.
>
>     -- 
>     Álvaro Herrera              Valdivia, Chile  —
>     https://www.EnterpriseDB.com/ <https://www.EnterpriseDB.com/;
>     "La primera ley de las demostraciones en vivo es: no trate de usar el
>     sistema.
>     Escriba un guión que no toque nada para no causar daños." (Jakob Nielsen)
>
>
>
> -- 
> Wells Oliver
> wells.oliver@gmail.com <mailto:wellsoliver@gmail.com>

-- 
Angular momentum makes the world go 'round.

view thread (10+ messages)

Message-ID: <07ed72a9-52dc-2c26-596e-7e80315ceb11@gmail.com>
Permalink:  ../07ed72a9-52dc-2c26-596e-7e80315ceb11@gmail.com/
Also on:    postgresql.org/message-id/07ed72a9-52dc-2c26-596e-7e80315ceb11@gmail.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-admin@postgresql.org
  Cc: ronljohnsonjr@gmail.com, pgsql-admin@lists.postgresql.org
  Subject: Re: 13.4 on RDS, SSL SYSCALL EOF on restore
  In-Reply-To: <07ed72a9-52dc-2c26-596e-7e80315ceb11@gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox