6

毎秒数十回の r/w クエリを処理する PostgreSQL インスタンスがあります。

  • インスタンスタイプ: db.m3.2xlarge
  • インスタンス プロビジョンド IOPS (SSD): 1000
  • インスタンスのストレージ サイズ: 100 GB 、データベースのサイズは約 5 ～ 10 GB です。

読み取り/書き込みクエリを使用して、数百の同時クライアントにサービスを提供しています。それでも、Cloudwatch Monitoring を見ると、20 ～ 60 の範囲の IOPS が示されています。

そして、Read IOPS はほぼ 0 です。

ここに画像の説明を入力

これは、何百もの接続とクライアントが常に読み取り/書き込みクエリを実行していると正しくありませんか? Postgres の構成は標準であり、fsync をオフにしませんでした。

キャッシュは非常に効果的で、データベース サイズが 5 GB の場合、IOPS は問題になりませんか? または AWS 監視コンソールが間違っていますか?

1000 IOPS を支払うと、この db インスタンスに 300 ドル余分にかかります。購入できる最小 IOPS は 1000 です。

IOPS なしでできるかどうか疑問に思っていますか?

  • または、AWS の監視が正しくありませんか?
  • または、現在の 20 IOPS は、非 IOPS サーバーを使用している場合、サーバーのパフォーマンスを低下させますか?
  • または、5 GB のデータベースではほとんどがキャッシュに収まり、IOPS は要因ではありませんか?
4

2 に答える 2

10

@CraigRingerは正しいです。データセットが完全にメモリに収まるほど小さい場合、挿入/更新トラフィックとログが唯一の消費 IOPS であるため、プロビジョニングされた IOPS は必要ありません。

しかし、誰かがこのトピックを見つけた場合に備えて、GP2 クレジットを使い果たしたときの CloudWatch は次のようになります。ご覧のとおり、読み取りと書き込みの IOPS グラフはあまりわかりませんが、読み取り/書き込みのレイテンシ グラフには大きなスパイクが見られます。

コンテキストとして、これらは分析に使用される 2 週間の PostgreSQL リードレプリカです。100GB GP2 (300 Base IOPS、$11.50/月) から 100GB io1 (1000 IOPS、$112.50/月) への切り替えは、これらのチャートの約 2/3 で発生します (レイテンシーのスパイクはもうありません)。より安価なオプションは、GP2 ストレージの量を増やすことでした。プロビジョンド IOPS は法外に高額ですが、この例では、負荷の高いワークロード中の予測可能な動作は理にかなっています。

RDS Cloudwatch グラフ: 読み取り/書き込み操作 RDS Cloudwatch グラフ: キューの深さ、レプリカ ラグ、R/W レイテンシ

于 2016-03-01T18:54:26.253 に答える
5

DB はほぼ完全に RAM にキャッシュされます。pg_buffercache(これは拡張機能を使用して確認できます)。これらの IOPS の数値は完全に予想されるものです。このサーバーは、プロビジョニングされた IOPS がなくても問題ないと思います。

インスタンスを再起動すると、キャッシュがバックアップされるため、しばらく遅くなりますが、5GB はそれほど多くありません。また、プロビジョニングされた iops があると、実際にはこれがさらに悪化します。これは、piops が最小 I/O レートを設定するだけでなく、最大値も設定するためです。これは目標レートであり、最低ではありません。

対照的に、通常のボリュームはpiops ボリュームよりもはるかに高い読み取り速度でバーストできるため、再起動後にキャッシュをウォーミング アップするとパフォーマンスが向上します。

ところで：

OS のディスク キャッシュからデータを読み込んで shared_buffers に戻すだけなので、データベースを再起動してもそれほど遅くはなりません。マシン全体を再起動した場合にのみ、しばらく速度が低下します。再起動せずにこれをシミュレートしたい場合は、Linux のdrop_caches機能を使用できます。

  echo 1 | sudo tee -a /proc/sys/vm/drop_caches

これは、バイナリとライブラリもメモリから追い出すため、実際には再起動後の状況よりも悪いです。システムは、実行中の非常に頻繁にアクセスされるバイナリとライブラリを RAM に読み込むため、最初は非常に激しく動作します。その後、再起動後のように、キャッシュの回復動作が見られるようになります。

また、構成されている接続が多すぎます。pgbouncer をインストールし、データベースの前に置き、max_connections を減らします。パフォーマンスが向上します。

于 2014-12-19T09:17:58.273 に答える