問題タブ [provisioned-iops]

プロビジョンド IOPSはハードリミットですか? IO スパイクがプロビジョニングされた IOPS の数を超える可能性はありますか?

質問に対する決定的な答えを簡単に見つけることができませんでした。ハードリミットとして強制されていると思いますが、ドキュメントはあまり決定的ではありません.

これが私を悩ませている質問です：

パフォーマンスに関して、標準の AWS ボリュームとプロビジョニングされた IOPS ボリュームを比較しようとしています。AWS のドキュメントでは、IOPS インスタンスは、必要な容量の 10% 以内の IO パフォーマンスを提供するように設計されていると記載されています。

私が知りたいのはこれです: たとえば、2000 IOPS のボリュームを作成しているとしましょう。これは、標準の AWS ボリュームと比較してどれくらい高速ですか?

Windowsマシンからパフォーマンスデータを収集できる小さなソフトウェアアプリを作成しようとしています。

これが私が使用するコードの一部であり、PrintScreenが正しい番号を教えてくれません。コードのどこが間違っているのか、コードのスケールが正しくないのはなぜか教えてください（デフォルトのスケールは1です）

PrintScreen： http: //postimage.org/image/6za0g7e4t/

私は当初、MySQL を 500 GB および 5000 IOPS に設定しています。書き込み IOPS の上限は 3500 です。

その後、IOPS パフォーマンスを向上させるために、MySQL 設定を 1.2 TB にアップグレードし、12000 プロビジョンド IOPS にすることにしました。ただし、まだ 3500 書き込み IOPS 制限に制限されているようです。

多くのユーザー情報とデータを格納する 1 つのテーブルを非常に頻繁に使用しています。読み取り IOPS は非常に低く、100 未満です。

書き込み IOPS が制限されるように、何か間違ったことをしたり、構成を誤ったりしたことはありますか?

複数のマシンを実行していないのに、多額の EC2 請求書に見舞われました。

請求書をもう少し詳しく調べたところ、プロビジョニングされた IOPS に対して月額 1100 ドルを支払っていたことがわかりました。これは、長い間電源が切られていたサーバーの 1000 IOPS の 10 ボリュームが原因であることが判明しました。

私の質問は、これらのボリュームをデタッチすると、それらの支払いが停止するかどうかです。または、これらのボリュームを完全に削除する必要がありますか?

再び必要になった場合に備えて、それらを維持するために少額の費用を支払うことは気にしませんが、それらを放置しておくためだけに月額 1100 ドルを支払うのはばかげています。

IOPS タイプの EBS を作成して EC2 ボリュームに接続したら、ストレージや IOPS などの設定を変更する方法はありますか? 私はそれを切り離して変更しても問題ありません。もちろん、データを保持したい。

できれば AWS コンソールで回答を探していますが、コマンド ライン アプローチでも大歓迎です。

Windows AMI を使用しています。

ストレージ IOPS 容量がいつボトルネックになるかを判断したいシミュレーション モデルに取り組んでいます (たとえば、HDD の IOPS は ~150 ですが、SSD の IOPS は 150,000 です)。そこで、いくつかの異なる操作 (プッシュ、プル、マージ、クローン) について、コマンド (git) で IOPS をベンチマークする方法を考え出そうとしています。

これまでのところ、iostat のようなツールを見つけましたが、レポートを 1 つのコマンドだけに制限する方法がわかりません。

私が思いつく最良のアイデアは、HDD IOPS 容量を決定し、実際のコマンドで時間を使用し、それがどれくらい続くかを確認し、それに IOPS を掛けると、それが私の IOPS になります。

しかし、これはもちろん非常にばかげています。実行時間は HDD の使用率ではなく CPU の使用率に関連している可能性があるため、その時間の HDD の使用率が 100% でな​​い限り、そのようなことを測定しても意味がありません。

では、コマンドの IOPS を測定するにはどうすればよいでしょうか?

アプリケーションを AWS クラウドに移行したい場合、アプリケーションが必要とする PIOPS の量をどのように判断できますか。アプリケーションに必要な PIOPS を計算できるツールはありますか? それともただのヒット＆トライアル方式??

毎秒数十回の 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 は要因ではありませんか?

AWS は、データと OS を別々の EBS ボリュームに保持することを推奨しています。EBS ボリュームを備えた EC2 で Web サーバーを実行しています。ベア VM に、次のものをインストールします。

データベースサーバーは別です。ウェブサーバーの場合、IOPS を高くすることでメリットが得られるのは上記の項目のうちどれですか?それが問題にならない項目はどれですか? 私の理解では、サーバー コードとログ ファイルは、より高い IOPS を持つ別の EBS ボリュームに移動する必要があります。それとも、すべてのもの (/etc にインストールしたソフトウェア、つまり Web サーバーを除く) を、より優れた IOPS を持つ別のボリュームに移動する必要がありますか?