web-dev-qa-db-ja.com

mongoサーバーに必要なEBSPIOPSを計算する方法は？

モンゴマシンでプロビジョニングされたIOPSEBSボリュームを使用したいのですが、使用するプロビジョニングされたIOPSの数を計算する方法について少し混乱しています。

現在、ボリュームあたり平均25 IOPS（読み取り+書き込み）を取得しています（4つのEBSボリュームを組み合わせて使用​​しています）。また、ピーク時にCPUが「待機中」の状態にあることも確認していますIO回。

私は質問を2つの部分に分けることができます-

  1. IOレイテンシーが減少するため、プロビジョニングされたEBS IOPSに移行した後、平均IOPSが大幅に増加します。IOPSカウントを超えないように、大きなバッファーを使用する必要がありますか？
  2. MongoセットアップにプロビジョニングされたIOPSの最適な数をどのように計算しますか？

ありがとう！

編集-Amazonからのボリューム平均キュー長を添付しました

（画像を貼り付けることができないので、ここにリンクがあります）

https://s3-eu-west-1.amazonaws.com/uploads-eu.hipchat.com/13432/91327/Mz2erjjMUcxMmDN/upload.png

mongodbamazon-ebsioiops
4
Nimrod Gutman

IOStat番号は、ここで影響を測定するために実際に必要なものであり、できれば時間の経過とともに、MongoDBの負荷に関連します（したがって、 [〜＃〜] mms [〜＃〜] with munin-node 監視用プラグイン）。 svctimeとキューサイズに高レベルの遅延が見られない場合（そして、おそらくアイドル状態のCPUがない場合は、IOWaitスパイクが見られます）。

そこにあるさまざまな分析からの一般的なコンセンサスは次のとおりです。

  • PIOPSを使用すると、レイテンシーがいくらか改善されます（これは、ワークロードのサイズやその他の要因によって異なります。 ここでは例を参照 ）
  • 一般に、レイテンシーとスループットの点ではるかに一貫したパフォーマンスが得られますが、これは常に当てはまるとは限りません（上記と同じレポート）
  • ただし、IOに関してストレスが見られない場合は、PIOPSを使用しても大きな違いは見られない可能性があります（より一貫したパフォーマンスに加えて）

あなたのIOはあなたのボトルネックではないようです（私はここで限られた証拠/情報に行きます）私はあなたが現在見ている100のPIOPSよりはるかに多くを見るつもりはないと思います、ただし、より予測可能なパフォーマンスが必要です。

2
Adam C