pg_dumpのリソースを貪欲にする方法
次のルールを使用して、pg_dumpを毎日呼び出すようにcronを構成しました。 # 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 基本的には動作します。データベースは比較的速く、指数関数的に成長します（ただし、指数はそれほど大きくありません）。現在、gzipされたダンプには約160MB必要です。データベースがダンプされると、システムはクロールを開始します。topコマンドを使用して見た負荷平均は約200, 200, 180でした。基本的に、サーバーはほとんど応答しません。 最初の質問は、ボトルネックがどこにあるかを決定する方法です。パフォーマンスの低下は重いI / O操作が原因ですか？テーブルロックの問題が原因ですか？多分それはメモリの問題ですか？pg_dumpコマンドの出力はコマンドにパイプされgzipます。それは順次ですか、つまり、ダンプ全体がメモリに配置され（スワッピングの問題ですか？）、次に圧縮されますか、それとも並行ですか（つまり、gzipは取得したものを圧縮し、それ以上待機します）？他の原因が考えられますか？ 2番目の質問は、システムの主な機能のためのダンプ操作は控えめにする方法です。私が理解している限りでは、データベースの整合性のため、ダンプに時間がかかることはありません。テーブル書き込みロックなどがあります。問題を制限する（またはデータベースの成長を考慮して遅延させる）にはどうすればよいですか。 3番目の質問は：すでに、より高度なデータベース構成について学ぶ時期ではありませんか？データベースのバックアップが実行されていない場合、システムは正常に動作しますが、おそらくデータベースダンプの問題が着信問題の最初の症状ですか？