web-dev-qa-db-ja.com

AWSR3.largeおよびR4.largeインスタンスでの奇妙なIOPSパフォーマンス

ここで説明するように、Windows Server2012R2イメージでRAID0を使用して4つの10GBGP2 EBSボリュームを使用しました： http://docs.aws.Amazon.com/AWSEC2/latest/WindowsGuide/raid-config.html 私が使用したインスタンスタイプはR3.largeでした

バーストプールがいっぱいになると4 * 3000（12K IOPS）になると予想していましたが、一貫して最大7480IOPSしか得られません。それはいいです。

その後、インスタンスタイプをR4.largeに変更しました。これは、より新しいバージョンのCPU（Ivy Bridgeの代わりにbroadwell）を使用することになっており、おそらくより高速です。他のすべてを同じ、同じディスク、同じOS、同じテストに保ちました。パフォーマンスはR3.largeよりも約6480IOPSで劣っていました。

ここでの問題は何ですか？同じインスタンスグループの最近の世代（R-「メモリインテンシブ」）のパフォーマンスが以前よりも低下するのはなぜですか？

amazon-web-servicesbenchmarkiops
1
user2629636

制約は、EBS自体ではなく、インスタンスタイプのネットワーク制限に起因しているようです。

必要な行の間にいくらかの読みがありますが、 EBS Optimized Instances ドキュメントは興味深い話をしています-あなたの数は実際にはインスタンスタイプがサポートできると主張する推定IOPSよりも優れています。

EBS最適化インスタンスには2つのネットワークパスがあり、そのうちの1つはインスタンスに出入りするすべてのIPトラフィックによって共有される1つのネットワークパスではなく、EBS接続専用です...したがって、ドキュメントにはこれについて明示されていませんが、速度インスタンスがEBSに最適化されているかどうかに関係なく、同じように見えます。違いは、最適化されたインスタンスの場合、EBSトラフィックが同じパイプを共有する必要がないことです。インスタンスへの合計帯域幅は2倍になり、半分がEBSに割り当てられ、半分がその他すべてに割り当てられます。

R3.largeインスタンスを使用するとおっしゃいましたが、それは表には示されていません...しかし、r3.xlargeから逆方向に外挿すると、そこにある数値はかなり小さくなります。

ドキュメントに記載されているように、IOPSの見積もりは「100％読み取り専用ワークロードに基づく丸められた概算」であり、リストされている接続以降は速度は全二重であり、読み取りと書き込みを組み合わせると、数値が大きくなる可能性があります。

type       network mbits/s mbytes/s estimated peak IOPS

r4.large            400       50        3,000
r4.xlarge           800      100        6,000

r3.large            250       31.25     2,000 (ratio-based speculation)
r3.xlarge           500       62.5      4,000

500 GiB gp2ボリュームの最初の512MiBをスキャンしてr3.largeの1つをテストすると、このネットワーク速度が確認されたようです。このマシンはEBSに最適化されておらず、で意味のあるワークロードを処理していませんでした。このテストが実行された時間。これは、r3.largeでの以前の観察結果と一致しています。私の設計上の仮定は、しばらくの間、これらのマシンの接続性は約0.25 Gbit/sであると想定していましたが、テストを繰り返す価値があるように見えました。もちろん、これはLinuxシステムですが、基本的な原則はすべて当てはまるはずです。

# sync; echo 1 > /proc/sys/vm/drop_caches; dd if=/dev/xvdh bs=1M count=512 | pv -a > /dev/null
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 14.4457 s, 37.2 MB/s
[35.4MB/s]

これは、約250メガビット/秒のネットワーク接続に非常によく似ています。ストレージスループットが必要な場合、帯域幅はそれほど多くありません。直感に反して、ワークロードがt2 CPUクレジットモデルに適切に適合している場合、実際には、r3から得られるよりもt2から得られるパフォーマンスが向上します。

2
Michael - sqlbot