Нет улучшения производительности при использовании параметра --jobs для pg_restore

Я использую pg_restore для восстановления базы данных Postgresql из резервной копии с помощью pg_dump. (как резервное копирование, так и восстановление происходит в PostgreSQL 12). Резервная копия создается с использованием параметра пользовательского формата --format=custom.

Восстановление резервной копии размером 10 ГБ занимает почти 30 минут. Время восстановления значительно увеличивается по мере увеличения размера резервной копии. Поэтому я попробовал параметр --jobs для улучшения времени восстановления.

Согласно документации, для восстановления базы данных будут использоваться одновременные подключения. объекты. Я проверил вывод восстановления и смог убедиться, что запущены параллельные потоки, равные значению параметра --jobs. Однако время восстановления не улучшилось ни при каком значении параметра --jobs.

Я знаю, что производительность зависит от аппаратной инфраструктуры. Но машина имеет 16 vcpus и 32GB RAM.

Я также пытался настроить Postgres, как указано в блоге со следующими конфигурациями, но по-прежнему без улучшения времени восстановления.


    work_mem = 32MB
    shared_buffers = 4GB
    maintenance_work_mem = 2GB
    full_page_writes = off
    autovacuum = off
    wal_buffers = -1

Есть ли что-то, что я пропустил? Как добиться улучшения времени восстановления?


postgresql pg-restore
person Swapnil17    schedule 21.10.2020    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Есть несколько вещей, которые могут быть проблемой:

  • pg_restore распараллеливается, одновременно выполняя несколько команд COPY и CREATE INDEX.

    Теперь, если в вашей базе данных есть одна большая таблица с одним большим индексом, распараллеливание вам не поможет.

  • Возможно, ваша система ввода/вывода находится на пределе своих возможностей. Тогда параллельный запуск процессов не улучшит производительность.

  • Известно, что если у вас много больших объектов, это замедляет обработку, и я не уверен, поможет ли распараллеливание или нет.

Никогда не устанавливайте full_page_writes или autovacuum в off, если вы не вернули их обратно в on после восстановления и не готовы выгрузить кластер базы данных в случае сбоя. Сомневаюсь, что прирост производительности того стоит, особенно для full_page_writes.

Один параметр, который вы забыли, это max_wal_size. Если вы поднимете это, это поможет написать производительность.

Кроме того, вы должны выяснить, где находится узкое место, прежде чем вы сможете его исправить.

Как насчет использования другого метода резервного копирования, такого как pg_basebackup, который обычно работает быстрее?

person Laurenz Albe    schedule 21.10.2020
comment
Есть одна таблица, в которой есть ссылки на blob oids. Большая часть размера резервной копии — это размер этих больших двоичных объектов. Существует не так много больших таблиц с точки зрения записей. Может ли это мешать работе? и любой указатель на то, как я могу проверить, является ли ввод-вывод узким местом? - person Swapnil17; 21.10.2020
comment
Да, большие объекты восстанавливаются медленно, и для них нет распараллеливания. Это, безусловно, причина. Я продлю ответ. - person Laurenz Albe; 21.10.2020
comment
Спасибо @laurenz. Причина, по которой мы используем pg_dump, связана с некоторыми случаями использования в бизнесе, когда нам необходимо выполнять выборочное восстановление схемы из резервной копии. pg_basebackup не позволил бы мне сделать это. - person Swapnil17; 21.10.2020
comment
Также для справки, есть ли общедоступная документация, в которой говорится, что большие двоичные объекты не могут быть распараллелены? - person Swapnil17; 21.10.2020
comment
Нет. На самом деле я не уверен на 100%, поэтому изменил ответ. Беглый взгляд на код меня не просветил. Но я уже видел жалобы на медленное восстановление со многими большими объектами. - person Laurenz Albe; 21.10.2020