Re: 13.4 on RDS, SSL SYSCALL EOF on restore

Поиск
Список
Период
Сортировка
От Wells Oliver
Тема Re: 13.4 on RDS, SSL SYSCALL EOF on restore
Дата
Msg-id CAOC+FBV2+mp-BJZfkjPaQCs_vf3UGpS8Z+N8mBj3i4SiZf1KWQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: 13.4 on RDS, SSL SYSCALL EOF on restore  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: 13.4 on RDS, SSL SYSCALL EOF on restore
Список pgsql-admin
Дерево обсуждения
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> 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/
"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)


--

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