如何使 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基本上，它有效。數據庫增長相對較快且呈指數增長（但指數不是很大）。目前 gzipped 轉儲大約需要 160MB。當數據庫被轉儲時，系統開始爬網。我使用該
top命令看到的平均負載約為200, 200, 180. 基本上伺服器幾乎沒有響應。第一個問題是如何確定瓶頸在哪裡。性能不佳是否是由於大量 I/O 操作造成的？它是由表鎖定問題引起的嗎？也許這是一個記憶體問題？命令的輸出通過
pg_dump管道傳送到gzip命令。它是順序的，即整個轉儲放在記憶體中（交換問題？）然後壓縮或併發（即gzip壓縮它得到的東西並等待更多）？會不會是其他因素造成的？第二個問題是如何使轉儲操作對系統主要功能的侵入性降低。據我了解，由於數據庫完整性，轉儲不會花費太多時間。有表寫鎖等。我可以做些什麼來限制問題（或延遲它，考慮到數據庫的增長）。
第三個問題：是不是該學習更高級的數據庫配置了？當沒有執行數據庫備份時，系統工作正常，但數據庫轉儲問題可能是傳入問題的第一個症狀？
哇。數量驚人的問題。我會嘗試解決一些問題，但這個答案還不完整。
如何確定瓶頸在哪裡。
使用
topfirst 查看轉儲期間發生了什麼。檢查程序CPU使用率，程序狀態。D意思是“等待 I/O”。性能不佳是否是由於大量 I/O 操作造成的？
是的，很可能。
它是由表鎖定問題引起的嗎？
也許。您可以使用
pg_stat_activity系統視圖查看轉儲期間 postgres 中發生了什麼。也許這是一個記憶體問題？
非常不可能。
pg_dump 命令的輸出通過管道傳送到 gzip 命令。它是順序的，即整個轉儲都放在記憶體中（交換問題？）
不，gzip 是一個在流模式下工作的塊壓縮器，它不會將所有輸入保存在記憶體中。
然後壓縮或併發（即gzip壓縮它得到的東西並等待更多）？
是的，它逐塊壓縮，輸出並等待更多。
會不會是其他因素造成的？
是的。
據我了解，由於數據庫完整性，轉儲不會花費太多時間。有表寫鎖等。我可以做些什麼來限制問題（或延遲它，考慮到數據庫的增長）。
轉儲持續時間對轉儲完整性沒有影響。通過所有 pg_dump 程序使用具有可重複讀取隔離級別的事務來確保完整性。正常 INSERT/UPDATE 沒有表寫鎖。備份期間只能阻止一些 DDL 操作（DROP TABLE、ALTER TABLE 等）。
現在是時候學習更高級的數據庫配置了嗎？當沒有執行數據庫備份時，系統工作正常，但數據庫轉儲問題可能是傳入問題的第一個症狀？
永遠不會太晚。從http://wiki.postgresql.org/wiki/Performance_Optimization開始。