主页 / dba / 问题 / 213734
Accepted
mikelus
Asked: 2018-08-02 00:47:11 +0800 CST

为什么并行 pg_restore 命令可能需要几个小时才能完成其非并行等效命令？

  • 772

我使用 pg_restore 使用以下命令从目录备份中恢复了 50 GB 数据库，该命令使用了 4 个作业：

pg_restore -d analytics -U postgres  -j 4 -v "D:\Program Files\PostgreSQL\10\backups\Analytics_08_2018__7_53_21.36.compressed"

我从命令行运行它。与非并行恢复相比，恢复耗时约2 小时。它似乎挂在还原作业结束时创建索引

pg_restore: launching item 2817 INDEX nidx_bigrams_inc_hits
pg_restore: creating INDEX "public.nidx_bigrams_inc_hits"
pg_restore: finished item 2965 TABLE DATA trigrams
pg_restore: launching item 2822 INDEX nidx_trigrams_inc_hits
pg_restore: creating INDEX "public.nidx_trigrams_inc_hits"
pg_restore: finished item 2823 INDEX nidx_unigrams_inc_hits
pg_restore: finished item 2822 INDEX nidx_trigrams_inc_hits
pg_restore: finished item 2817 INDEX nidx_bigrams_inc_hits
pg_restore: finished main parallel loop

这些 pg_restore “创建索引”作业中的每一个在 pg_stat_activity 中都具有“空闲”状态。另一个 pg_restore 作业在提交时是“空闲”的。

我希望并行还原能够比默认还原更快地完成，并且它似乎一直在这样做，直到它在大约 15 分钟后挂在那里。此服务器上没有发生太多其他事情。当我在作业完成之前检查它们时，索引似乎是完整的，即它们与原始数据库索引的大小相同。与非并行还原相比，并行还原作业需要更长的时间来完成/提交是否有任何特殊原因？如果我不能依赖工作持续时间，我想在灾难恢复情况下为此做好准备并排除并行。

顺便说一句，我知道基于文件系统的备份而不是逻辑备份，但我暂时只对逻辑感兴趣。

postgresql postgresql-10

2 个回答

  1. Best Answer

    这可能只是数据库争用。

    进行并行转储，您的 postgres 可以一次写入许多不同的文件，因此负载可以分散。

    进行并行恢复时，postgres 必须同时管理来自作业+1 连接的所有 [重量级] 流量，所有这些都填充缓冲区缓存中的数据页面并将它们写入磁盘。要创建索引，您需要重新读取数据页并扫描它们；一次对许多表执行此操作会给缓冲区缓存带来很大压力…… postgres 需要做更多的工作。

    此外，您已经指定了四个作业 - 您的数据库 [服务器] 是否有足够的 CPU/内核来支持它？如果不是这样，那么额外的作业仍然会被启动，但是会在操作系统级别受到争用，因为当[可怜的]机器试图“同时”运行它们时，它们会在内存不足的情况下被切换。在较小的服务器上，您可能会从运行两个作业中获得[一些] 好处，但不仅如此，而且成本很快就会超过好处。

    • 4

  2. 发生这种情况的另一个原因是pg_restore需要您多次输入密码（每个进程一次）。例如，如果这是您的命令：

    pg_restore --jobs=8 --clean -d example -C --no-owner --no-acl -U example -h 127.0.0.1 -W db.dump 
Password: 
Password: 
Password: Password: Password: Password: Password: Password: Password: Password:

    最后一行要求您输入密码，然后输入回车键八次，或总共十次。

    • 0

相关问题