如何使pg_dump减少资源贪婪

我已经配置cron使用以下规则每天调用pg_dump：

# xyz database backups:
00 01 * * * root umask 077 && pg_dump --user=xyz_system xyz | gzip > /var/xyz/backup/db/xyz/`date -u +\%Y\%m\%dT\%H\%M\%S`.gz

基本上，它可以工作。数据库相对快速且呈指数增长（但是指数不是很大）。目前，压缩后的转储大约需要160MB。转储数据库后，系统开始爬网。我使用该top命令看到的平均负载约为200, 200, 180。基本上，服务器几乎没有响应。

第一个问题是如何确定瓶颈在哪里。I / O操作繁重是否会导致性能不佳？是由表锁定问题引起的吗？也许是内存问题？pg_dump命令的输出通过管道传递到gzip命令。它是顺序的，即整个转储都放在内存中（交换问题？），然后压缩或并发（即gzip压缩得到的内容并等待更多）？可能是由其他因素引起的吗？

在第二个问题是如何使倾倒操作该系统的主要功能侵扰程度较低。据我了解，由于数据库的完整性，转储不会花费太多时间。有表写锁等。我可以做些什么来限制问题（或考虑数据库的增长而延迟它）。

在第三个问题：是否已经时间来了解更多的高级数据库配置？当没有执行数据库备份时，系统运行正常，但是数据库转储问题也许是传入问题的第一个症状？

哇。问题数量惊人。我将尝试解决一些问题，但是此答案尚未完成。

如何确定瓶颈在哪里。

top首先使用它来查看转储过程中发生的情况。检查进程CPU使用率，进程状态。D表示“等待I / O”。

I / O操作繁重是否会导致性能不佳？

是的，很有可能。

是由表锁定问题引起的吗？

也许。您可以使用pg_stat_activity系统视图查看转储过程中postgres中的情况。

也许是内存问题？

不太可能。

pg_dump命令的输出通过管道传递到gzip命令。它是顺序的，即整个转储都放在内存中（交换问题吗？）

不可以。gzip是在流模式下工作的块压缩器，它不会将所有输入都保留在内存中。

然后压缩或并发（即gzip压缩得到的内容并等待更多）？

是的，它逐块压缩，输出并等待更多。

可能是由其他因素引起的吗？

是。

据我了解，由于数据库的完整性，转储不会花费太多时间。有表写锁等。我可以做些什么来限制问题（或考虑到数据库的增长，将其延迟）。

转储持续时间对转储完整性没有影响。所有pg_dump进程使用一个具有可重复读取隔离级别的事务来确保完整性。没有表写锁。

现在已经是时候学习更高级的数据库配置了吗？当没有执行数据库备份时，系统运行正常，但是数据库转储问题可能是传入问题的第一个症状？

亡羊补牢为时不晚。从http://wiki.postgresql.org/wiki/Performance_Optimization开始。

我建议您看一下Postgresql的连续归档。这是使用pg_dump的优势：

1. 无需每次都进行完整备份。一开始，一个完整备份就足够了，但是建议例如每隔几天进行一次完整备份。
2. 当数据库增加时，恢复速度非常快。
3. 还原到其他点的能力（即时点恢复）。
4. 您将每小时（大约30分钟）进行一次增量备份。这可以配置，并且还取决于更新活动。

但是，存在一些缺点（在大多数情况下可能不是问题）：

1. 通常需要更多空间，因为这些是二进制备份。可以压缩数据库文件夹。
2. 您不能将它们还原到其他体系结构（二进制数据）上。