web-dev-qa-db-ja.com

RDS Postgresでの高い書き込みスループットの診断

私はRDSでPostgres 9.6.1を使用していますが、予想よりも桁違いに高い書き込みスループットが見られます。約40,000,000バイト/秒のWriteThroughputが発生しています。どこから来たのかを追跡するために、私は以下を調べました：

Pg_stat_statementsをインストールし、定期的に実行しています。

SELECT sum(shared_blks_dirtied) from pg_stat_statements

そして、私のクエリは毎秒最大で約30ブロックしかダーティにしていないようです。ブロックは8kBですよね？つまり、1秒あたりわずか240 kBです。 （tempブロックとローカルブロックもチェックしましたが、ほとんどダーティ化したり、まったく書き込んでいません。また、pg_stat_statementsが追跡する一意のステートメントの制限に達していないことも確認しました）。

私は自分のログも見ており、このサイズについて5分ごとにチェックポイントが実行されているのがわかります。

LOG:  checkpoint complete: wrote 8538 buffers (0.4%); 0 transaction log file(s) added, 0 removed, 3 recycled; write=269.825 s, sync=0.021 s, total=269.921 s; sync files=2349, longest=0.010 s, average=0.000 s; distance=39599 kB, estimate=39599 kB

つまり、約40 MB/5分= 133 kB /秒です。これは、pg_stat_statementsに表示されるのと同じ桁数です。

だから私は少し混乱しています...私は数学を間違っていますか、それとも書き込みスループットを生成しているものが何であるかを確認するためにどこかに探しているはずですか？

もう1つ言及する必要があります。テーブルとスキーマがたくさんあります。約25,000のスキーマと合計200万のリレーションです。 （そして、私は新しいスキーマを一般に1分に数回作成/ドロップします）。非常にアグレッシブな構成でも、autovacuumがこれに対応できないことがわかったため、書き込みパターンに基づいてテーブルを手動でバキュームおよび分析し、autovacuumのしきい値を上方に調整して、実際に手動バキュームを実行しました。ほとんどの場合、autovacuumが実行される前にそこに到達します。私の手動バキュームがpg_stat-statementsに表示されることを確認したので、それらが生成するすべての書き込みは、上記の分析ですでに説明されていると思いますが、そうでない可能性がありますか？

postgresqlamazon-rdspostgresql-9.6
6
josh

私の書き込みスループットの大部分は統計収集者からのものであることがわかりました。私のデータベースには非常に多くの関係があるため、統計データは異常に大きくなります。私は統計を一時的にクリアすることで問題を診断することができました：

SELECT pg_stat_reset()

これにより、書き込みスループットが即座に劇的に低下しました。今後の問題を解決するために、次の設定を使用して、統計ディレクトリをハードドライブではなくRAMディスクにリダイレクトしました： http://docs.aws.Amazon.com/AmazonRDS/latest/UserGuide /CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.FeatureSupport.RamDisk

最終結果は、CloudWatchが40 MB /秒ではなく、約400 KB /秒のスループットを報告するようになったことです。

7
josh