我已经configurationcron使用以下规则每天调用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操作繁重导致性能下降吗？ 是由表locking问题引起的？ 也许这是一个记忆问题？ pg_dump命令的输出pg_dump送到gzip命令。 它是顺序的，即整个转储放在内存（交换问题？），然后压缩或并发（即gzip压缩得到的东西，等待更多）？ 可能是由其他因素引起的？
第二个问题是如何使倾销行为对系统的主要function不那么侵犯。 据我了解，由于数据库的完整性，转储不会花费太多时间。 有表写锁，等等。我可以做些什么来限制这个问题（或考虑到数据库的增长而延迟）。
第三个问题 ：现在是不是应该学习更高级的数据库configuration了？ 系统工作正常，当数据库备份不执行，但也许数据库转储问题是传入问题的第一个症状？
哇。 惊人数量的问题。 我会尽力解决一些，但是这个答案还没有完成。
如何确定瓶颈在哪里。
首先使用top查看转储过程中发生了什么。 检查进程CPU使用情况，进程状态。 D意思是“等待I / O”。
I / O操作繁重导致性能下降吗？
是的，最有可能的。
是由表locking问题引起的？
也许。 您可以使用pg_stat_activity系统视图来查看转储过程中postgres中发生了什么。
也许这是一个记忆问题？
非常不可能。
pg_dump命令的输出被传送到gzip命令。 它是顺序的，即整个转储放在内存中（交换问题？）
不，gzip是一个工作在stream模式下的块压缩器，它不会将所有input保存在内存中。
然后压缩或并发（即gzip压缩它得到什么，等待更多）？
是的，它会逐块压缩，输出并等待更多。
可能是由其他因素引起的？
是。
据我了解，由于数据库的完整性，转储不会花费太多时间。 有表写锁，等等。我可以做些什么来限制这个问题（或考虑到数据库的增长而延迟）。
转储时间对转储完整性没有影响。 通过所有pg_dump进程使用具有可重复读取隔离级别的一个事务来确保完整性。 没有表写入锁。
现在是时候了解更高级的数据库configuration了吗？ 系统工作正常，当数据库备份不执行，但也许数据库转储问题是传入问题的第一个症状？
不算太迟。 从http://wiki.postgresql.org/wiki/Performance_Optimization开始。
我build议你看看postgresql的连续存档 。 以下是使用pg_dump的优点：
但是，有一些缺点（在大多数情况下这可能不成问题）：