使用 pg_restore 的 --jobs 参数没有提高性能答案

【问题标题】：No performance improvement using --jobs parameter for pg_restore使用 pg_restore 的 --jobs 参数没有提高性能
【发布时间】：2020-10-21 07:46:46
【问题描述】：

我正在使用pg_restore 来恢复使用pg_dump 备份的 Postgresql 数据库。（备份和恢复都在 PostgreSQL 12 上进行）。使用自定义格式选项--format=custom 进行备份。

10 GB 备份的还原大约需要 30 分钟。随着备份大小的增加，恢复时间会显着增加。所以我尝试了--jobs 参数来缩短恢复时间。

根据documentation，将使用并发连接来恢复数据库对象。我验证了 restore 的输出，并且可以验证启动的并行线程等于 --jobs 参数的值。但是，--jobs 参数的任何值都没有改善恢复时间。

我知道性能取决于硬件基础架构。但是这台机器有 16 个 vcpus 和 32GB 内存。

我还尝试使用以下配置调整 blog 中提到的 Postgres，但恢复时间仍然没有改善。

工作内存 = 32MB 共享缓冲区 = 4GB 维护工作内存 = 2GB full_page_writes = 关闭自动真空 = 关闭 wal_buffers = -1

有什么我错过的吗？如何缩短恢复时间？

【问题讨论】：

【解决方案1】：

有几件事可能是问题：

pg_restore 通过同时运行多个COPY 和CREATE INDEX 命令进行并行化。

现在，如果您的数据库有一个带有单个大索引的大表，那么并行化将无济于事。
也许您的 I/O 系统已达到极限。那么并行运行进程不会提高性能。
如果您有很多大对象，众所周知这会减慢处理速度，我不确定并行化是否有帮助。

永远不要将full_page_writes 或autovacuum 设置为off，除非您在还原后将它们设置回on，并准备好在发生崩溃时转储数据库集群。我怀疑性能提升是否值得，尤其是对于full_page_writes。

您忘记的一个参数是max_wal_size。如果你提出这个问题，它将有助于编写性能。

除此之外，你必须找出瓶颈在哪里才能解决它。

如何使用其他备份方法，例如通常更快的 pg_basebackup？

【讨论】：