大手クラウドサービスであるAmazon EC2では、9種類ものインスタンスタイプ(サーバの種類)から、利用したいスペックのサーバを選択できます。また、EC2のサーバは、4ヶ所ものリージョン(アメリカ東海岸、同西海岸、ヨーロッパ西部、シンガポール)から稼動させる場所を選択することができます。
ここで、気になるのが、Amazon Web Servicesの説明ページで、各インスタンスタイプの公表スペック差異として、EC2独自のCPU単位である"ECU"の数値や、IO性能のModerate(中)やHigh(高)で、どのくらいパフォーマンスが違うのかが見え辛いといった点。
また、一部の場所ではパフォーマンスが出ていない等の話が以前に出ていましたが、4ヶ所のロケーション(Region)によって、各場所でのインスタンス性能が全く同じなのか等も気になるところ。
ここを解明すべく、各種ベンチマークを実行してみました。
(ブログのエントリというよりは、検証レポートっぽくなってしまったw)
計測・比較を行った項目
観点としては、9種類のインスタンス(サーバ)のディスク・CPUパワーの性能や、4ヶ所のリージョンで性能に差異があるかを確認しました。
- 9種類の各インスタンスでのCPUベンチマーク
- 姫野ベンチマークを利用
- 9種類の各インスタンスでのディスクI/Oベンチマーク
- 9種類の各インスタンスでの総合ベンチマーク
- unixbenchを利用
- 4ヶ所の各リージョンでのCPUベンチマーク
- 4ヶ所の各リージョンでのディスクI/Oベンチマーク
※ 注意点として、以降の結果は、クラウドサービスの性質から、時間帯や混雑具合によって大きく変わる可能性もあります。厳密に何度も取得・分析を行ったわけではないので、その点はご了承いただきたく思います。
計測・比較対象のインスタンスタイプ (Instance type)
via. Amazon EC2 Instance Types - Amazon Web Services
以下に、表形式でまとめておきます。
- 1ECU(EC2 Compute Unit)は、XeonもしくはOpteronの1.0〜1.2GHz相当となります。
- Price(価格)は、us-eastでLinuxプラットフォームを稼動させた場合の1時間あたりの料金です。(2010/07現在)
Standard Instances
Instance | Price | Memory | CPU | Disk | I/O performance |
---|---|---|---|---|---|
Small Instance [m1.small] (32-bit) (*Default) |
$0.085 | 1.7 GB | 1 ECU (1 virtual core with 1 ECU) |
160 GB | Moderate |
Large Instance [m1.large] (64-bit) |
$0.34 | 7.5 GB | 4 ECU (2 virtual cores with 2 ECU each) |
850 GB | High |
Extra Large Instance [m1.xlarge] (64-bit) |
$0.68 | 15 GB | 8 ECU (4 virtual cores with 2 ECU each) |
1690 GB | High |
High-CPU Instances
Instance | Price | Memory | CPU | Disk | I/O performance |
---|---|---|---|---|---|
High-CPU Medium Instance [c1.medium] (32-bit) |
$0.17 | 1.7 GB | 5 ECU (2 virtual cores with 2.5 ECU each) |
350 GB | Moderate |
High-CPU Extra Large Instance [c1.xlarge] (64-bit) |
$0.68 | 7 GB | 20 ECU (8 virtual cores with 2.5 ECU each) |
1690 GB | High |
High-Memory Instances
Instance | Price | Memory | CPU | Disk | I/O performance |
---|---|---|---|---|---|
High-Memory Extra Large Instance [m2.xlarge] (64-bit) |
$0.50 | 17.1 GB | 6.5 ECU (2 virtual cores with 3.25 ECU each) |
850 GB | Moderate |
High-Memory Double Extra Large Instance [m2.2xlarge] (64-bit) |
$1.20 | 34.2 GB | 13 ECU (4 virtual cores with 3.25 ECU each) |
850 GB | High |
High-Memory Quadruple Extra Large Instance [m2.4xlarge] (64-bit) |
$2.40 | 68.4 GB | 26 ECU (8 virtual cores with 3.25 ECU each) |
1690 GB | High |
Cluster Compute Instances
Instance | Price | Memory | CPU | Disk | I/O performance |
---|---|---|---|---|---|
Cluster Compute Quadruple Extra Large Instance [cc1.4xlarge] (64-bit) |
$1.60 | 23 GB | 33.5 ECU (2 x Intel Xeon X5570, quad-core "Nehalem" architecture) |
1690 GB | Very High (10 Gigabit Ethernet) |
計測・比較対象のリージョン (Region)
以下4ヶ所が対象です。(現在利用可能なリージョン全て)
- us-east (アメリカ東海岸)
- us-west (アメリカ西海岸)
- ap-southeast (アジア・シンガポール)
- eu-west (ヨーロッパ西部)
実際にインスタンスで利用されていたCPU
実際に、検証を行う際に、"/proc/cpuinfo"の情報から確認したCPUが以下となります。
Instance type | CPU model |
---|---|
m1.small | Dual-Core AMD Opteron(tm) Processor 2218 HE x 1core (us-eastのみ) Intel(R) Xeon(R) CPU E5430 @ 2.66GHz x 1core (上記以外) |
m1.large | Intel(R) Xeon(R) CPU E5430 @ 2.66GHz x 2cores |
m1.xlarge | Intel(R) Xeon(R) CPU E5430 @ 2.66GHz x 4cores |
c1.medium | Intel(R) Xeon(R) CPU E5410 @ 2.33GHz x 2cores |
c1.xlarge | Intel(R) Xeon(R) CPU E5410 @ 2.33GHz x 8cores |
m2.xlarge | Intel(R) Xeon(R) CPU X5550 @ 2.67GHz x 2cores |
m2.2xlarge | Intel(R) Xeon(R) CPU X5550 @ 2.67GHz x 4cores |
m2.4xlarge | Intel(R) Xeon(R) CPU X5550 @ 2.67GHz x 8cores |
cc1.4xlarge | Intel(R) Xeon(R) CPU X5570 @ 2.93GHz x 16cores |
姫野ベンチマークによるCPUベンチマーク(インスタンスタイプ別)
CPUベンチマークとして「姫野ベンチマーク」を利用してみました。
利用したのは、"C, static allocate version"のMサイズのソースコードを実機でコンパイルしたものです。
via. http://accc.riken.jp/HPC/HimenoBMT/download1.html#list3
以下ベンチマークの対象は、"us-east"で稼動させたEC2インスタンス全種(9種類)です。結果値の単位は"MFLOPS"。
Instance type | MFLOPS measured | (vCore) |
---|---|---|
m1.small | 324.68 | (x1) |
c1.medium | 774.60 | (x2) |
m1.large | 892.18 | (x2) |
m1.xlarge | 880.10 | (x4) |
c1.xlarge | 1044.82 | (x8) |
m2.xlarge | 1544.97 | (x2) |
m2.2xlarge | 1600.40 | (x4) |
m2.4xlarge | 1572.73 | (x8) |
cc1.4xlarge | 1676.40 | (x16) |
上記の結果を見る感じ、姫野ベンチマークでは、マルチコアを使い切った感じではない性能値が算出されているようですね。
(追記: 参考として、上記表の横にvCore数を並べてみました。 via. http://twitter.com/namikawa/status/19240827882)
意外だったのは、5ECU(2.5ECU x 2)のc1.mediumより、4ECU(2ECU x 2)のm1.largeの性能値が良いことですね。CPUの型番だけを見ていると、この結果には納得なのですが。c1.mediumはXeon E5410(2.33GHz)で、m1.largeはXeon E5430(2.66GHz)ですからね。
m1.smallは、1つのCPUを、2.5〜3つのインスタンスで共有している感じですかね。OS上では、steal値が60%前後だということを考えると、この結果にもおおよそ納得といったところ。
m2.xlarge系である「High-Memory Instances」のスコアが良い感じですね。
ちなみに、参考までですが、我が家の物理サーバで姫野ベンチマークを実行した結果は、以下のようになりました。
CPU model | MFLOPS measured |
---|---|
Intel(R) Core(TM)2 Duo CPU P9500 @ 2.53GHz x 2cores | 1503.59 |
AMD Phenom(tm) 9950 Quad-Core Processor x 4cores | 1192.06 |
AMD Athlon(tm) 64 Processor 3500+ x 1core | 814.56 |
Dual-Core AMD Opteron(tm) Processor 1210 x 2cores | 725.76 |
Intel(R) Pentium(R) III CPU family 1.13GHz x 2cores | 121.00 |
※ 本当は、Core i7やPentium系などもあるのだが、ネイティブUnix/Linuxが乗っていないorz
姫野ベンチマークによるCPUベンチマーク(リージョン別)
続いて、各リージョン(Region)別でも姫野ベンチマークでCPU性能を計測してみました。
尚、ここでは、CPU単体のスペック種別(ECU的、型番的の双方)が違うインスタンス※を中心に、2 virtual coresのインスタンスのみと、m1.small(一番、利用頻度が多そうなので)を計測してみました。
- m1.small - (1ECU: Opteron 2218 HE or Xeon E5430) x 1core
- c1.medium - (2.5ECU: Xeon E5410) x 2cores
- m1.large - (2ECU: Xeon E5430) x 2cores
- m2.xlarge - (3.25ECU: Xeon X5550) x 2cores
※ コア数は同じで、CPUの種類だけが違うもの。
以下ベンチマークの対象は、上記4種類のEC2インスタンスを4ヶ所のリージョン毎にベンチマークしたものです。
us-east | us-west | ap-southeast | eu-west | |
---|---|---|---|---|
m1.small | 324.68 | 322.79 | 331.26 | 326.26 |
c1.medium | 774.60 | 764.04 | 779.00 | 780.13 |
m1.large | 892.18 | 882.63 | 883.45 | 887.28 |
m2.xlarge | 1544.97 | 1603.40 | 1558.68 | 1604.94 |
m1.smallに限っては、"us-east"とそれ以外で、CPUモデルが違うものの、ベンチマークスコアはほとんど同じです。その他のインスタンスタイプでは、CPUモデルも型番も同じなので、当然ほぼ同じスコアとなっています。CPUについては、リージョン毎の性能差はないようです。
dbenchによる、ディスクI/Oベンチマーク (インスタンスタイプ別)
次に、dbenchを使ったディスクI/Oのベンチマークです。
以下は、各インスタンスで実際に実行したコマンドと結果例(m1.large)となります。(4 clients想定)
# dbench -c /client.txt 4 Operation Count AvgLat MaxLat ---------------------------------------- NTCreateX 3290828 0.025 1218.637 Close 2417179 0.003 20.170 Rename 139367 0.053 361.139 Unlink 664704 0.079 3567.164 Deltree 80 4.227 17.643 Mkdir 40 0.005 0.006 Qpathinfo 2982727 0.012 680.247 Qfileinfo 522615 0.002 10.304 Qfsinfo 547034 0.071 57.628 Sfileinfo 268069 0.054 932.573 Find 1153275 0.035 66.888 WriteX 1640191 0.047 1365.309 ReadX 5159241 0.008 679.026 LockX 10720 0.007 6.386 UnlockX 10720 0.005 5.440 Flush 230684 8.317 4875.339 Throughput 172.128 MB/sec 4 clients 4 procs max_latency=4875.352 ms
instance-rootタイプ
で、以下が"us-east"の各インスタンス(S3 AMIから起動したinstance-rootタイプ)で実行したディスクI/Oパフォーマンスの結果。
Throughputの単位はMB/sec、max_latencyの単位はmsです。
Throughput | max_latency | |
---|---|---|
m1.small | 83.3971 | 3152.082 |
c1.medium | 144.739 | 1847.075 |
m1.large | 172.128 | 4875.352 |
m1.xlarge | 197.14 | 2492.915 |
c1.xlarge | 198.618 | 3100.112 |
m2.xlarge | 276.09 | 4059.14 |
m2.2xlarge | 293.215 | 3569.074 |
m2.4xlarge | 313.331 | 3623.604 |
公表スペックで、I/Oパフォーマンスは、"Moderate"、"High"、"Very High"の3種類でしたが、同じ"Moderate"のm1.smallとc1.medium、m2.xlargeでも、割と差がある感じです。(公表スペックのI/Oパフォーマンスは、ディスクだけではなくネットワークのI/Oも含まれているのでしょう。)
あと、m2系の「High-Memory Instances」は、レイテンシが高めですが、パフォーマンスは良さそうです。
余談ですが、本当は、各デバイスに対して計測を行いたかったのですが、dbenchの"-c"オプションによるloadfileでの場所指定が上手く動いていなかったようで、結局ルートパーティション(/dev/sda1)への計測になっているものと推測しています。(ソース嫁、ですね)
ebsタイプ
次に、「Cluster Compute Instance」な"cc1.4xlarge"が、EBS AMIベースのものしかないので、いくつかEBSブートで稼動させたインスタンスで同様に結果を測定してみました。いずれも"us-east"で稼動させています。
Throughput | max_latency | |
---|---|---|
c1.medium | 45.1286 | 692.144 |
m1.large | 39.8205 | 674.802 |
m2.xlarge | 69.861 | 1167.158 |
cc1.4xlarge | 137.968 | 382.083 |
こちらから、EBSなディスクタイプのレイテンシは低いが、instance-rootほどのパフォーマンスは出ていないことがわかります。ですが、"cc1.4xlarge"タイプの結果はさすがに良いですね。
hdparmによる、ディスクI/Oベンチマーク (インスタンスタイプ別)
dbenchとは別に、ディスクI/Oパフォーマンスを計る指標として、hdparmを利用します。
こちらは、ディスクの読み込みスループット計測がメインですが、ルートパーティションのディスク(/dev/sda1)、エフェメラルディスク(/dev/sdb)、EBSボリュームとしてアタッチしたディスク(/dev/sdf1)の3種類に対して実行しました。ここでの結果値は、"-t"オプションを利用し、連続で5回実行した平均値となります。
-t
http://www.linux.or.jp/JM/html/hdparm/man8/hdparm.8.html
ベンチマーク及び比較目的で、デバイス読み込みを測定する。有意な結果を得るためには、少なくとも数メガバイトの空きメモリがあり、他にアクティブなプロセスがない状態で、この操作を 2, 3 回繰り返すべきである。これはデータのキャッシュがない状態から、バッファキャッシュを通してディスクを読み出す速度を表示する。これは、ファイルシステムのオーバーヘッドなしに、そのドライブが Linux でどれだけ連続データ読み込み速度を維持できるかを測定するものである。測定の正確さを上げたいのであれば、 -t の実行の間に BLKFLSBUF ioctl を使ってバッファキャッシュをクリアする。
instance-rootタイプ
以下は、"us-east"の各インスタンスに対して行った実行結果です。結果値の単位はMB/secです。
/dev/sda1 | /dev/sdb | /dev/sdf1 | |
---|---|---|---|
m1.small | 252.872 | 275.708 | 66.86 |
c1.medium | 271.04 | 306.462 | 66.152 |
m1.large | 153.548 | 166.746 | 75.746 |
m1.xlarge | 196.758 | 170.98 | 67.002 |
c1.xlarge | 196.282 | 197.344 | 75.318 |
m2.xlarge | 577.024 | 375.936 | 79.056 |
m2.2xlarge | 612.69 | 432.278 | 86.486 |
m2.4xlarge | 637.192 | 504.624 | 78.196 |
どういうわけか、m1.smallとc1.mediumの32ビットプラットフォームなインスタンスの値が、思いの外すごく良いです・・・。あと、m2系の「High-Memory Instances」のパフォーマンスも抜けています。
ルートパーティションのディスク(/dev/sda1)とエフェメラルディスク(/dev/sdb)については、それほど大きな差は見られないので、性能は同等かもしれません。
EBSボリュームについては、どのインスタンスタイプでも同様の結果かな、と思っていましたが、そうでもないようです(時間帯や割当区域レベルの差かもしれませんが・・・)。EBSのスループットは概ね「65〜85MB/sec」ですね。
ちなみに、これも参考までですが、我が家の物理サーバでhdparmを実行した結果は、以下のようになりました。
device | Throuput |
---|---|
PATA 5400rpm x 1 | 44.944 |
SATA 7200rpm x 1 | 76.75 |
SATA 7200rpm x 2 (RAID0) | 131.38 |
SATA 7200rpm x 2 (RAID1) | 104.384 |
SATA 7200rpm x 4 (RAID0) | 294.486 |
SATA 7200rpm x 4 (RAID5) | 172.188 |
SATA 7200rpm x 4 (RAID1+0) | 169.616 |
ebsタイプ
dbench同様、EBSブートなインスタンスでも測定してみました。こちらも"us-east"で実施。
/dev/sda1 | /dev/sdb | /dev/sdf1 | |
---|---|---|---|
c1.medium | 77.212 | - | - |
m1.large | 74.126 | - | - |
m2.xlarge | 86.244 | - | - |
cc1.4xlarge | 140.594 | 234.084 | 84.992 |
こちらでも、"cc1.4xlarge"タイプの結果は抜けています。
EBSボリュームについては、それほどスループットは大きく出ませんが、レイテンシも低く、終始安定した書き込みを行っている感覚を受けました。(結果にバラつきが出ない。値が小さいので、そう見えているだけ?)
dbenchによる、ディスクI/Oベンチマーク (リージョン別)
続いて、CPUベンチマークと同様に、各リージョンで差異が見られるかを確認してみました。
結果値の単位は、先ほどと同様、"Throuput[MB/sec] (max_latency[ms])"となります。
us-east | us-west | ap-southeast | eu-west | |
---|---|---|---|---|
m1.small | 83.3971 (3152) | 101.017 (1830) | 99.8322 (1842) | 97.7665 (2387) |
c1.medium | 144.739 (1847) | 150.138 (1919) | 139.443 (2129) | 137.977 (2464) |
m1.large | 172.128 (4875) | 212.781 (1870) | 200.576 (2194) | 222.317 (2063) |
m2.xlarge | 276.09 (4059) | 111.084 (19730) | 233.529 (7937) | 110.98 (10703) |
こちらは、若干バラつきが見られます。特に、m2.xlargeタイプのインスタンスについては、全体的にレイテンシが大きく、us-westとeu-westでは期待していたパフォーマンスが出ない結果となりました。これについては、時間帯を変えてやり直しも行ったのですが、結果はそれほど変わらず。
m1系の「Standard Instances」については、us-east以外のリージョンがやや速いかな、という印象。
というわけで、あくまで参考程度に。
hdparmによる、ディスクI/Oベンチマーク (リージョン別)
続いて、hdparmでも同様に、各リージョンで差異が見られるかを確認してみました。
結果値の単位は、"Throuput[MB/sec]"となります。
m1.small
us-east | us-west | ap-southeast | eu-west | |
---|---|---|---|---|
/dev/sda1 | 252.872 | 264.604 | 353.44 | 292.544 |
/dev/sdb | 275.708 | 292.33 | 346.996 | 296.948 |
/dev/sdf1 | 66.86 | 71.07 | 69.49 | 67.284 |
ap-southeastのパフォーマンスが少しばかり良いように見えます。その他は、それほど大きな差は見られません。
c1.medium
us-east | us-west | ap-southeast | eu-west | |
---|---|---|---|---|
/dev/sda1 | 271.04 | 288.216 | 338.206 | 299.098 |
/dev/sdb | 306.462 | 293.586 | 312.514 | 308.778 |
/dev/sdf1 | 66.152 | 78.986 | 82.21 | 76.406 |
/dev/sda1でap-southeastの値がやや良いですが、こちらはそれほど大きな差は見られません。
m1.large
us-east | us-west | ap-southeast | eu-west | |
---|---|---|---|---|
/dev/sda1 | 153.548 | 179.554 | 218.848 | 217.414 |
/dev/sdb | 166.746 | 181.374 | 167.016 | 156.748 |
/dev/sdf1 | 75.746 | 71.666 | 73.814 | 69.5 |
/dev/sda1でap-southeastとeu-westの値がやや良いですね。それ以外は、それほど大きな差は見られません。
unixbenchによる、総合ベンチマーク
最後に、unixbenchを使った総合ベンチマークの値を載せておきます。
こちらはツール自体が少し古いこともあって、取得できていない値もあったりするのですが、何かの参考になれば。"us-east"の全種類のインスタンスに対してベンチマークを行いました。
以下は、実際にc1.mediumに対して実行した結果例です。
BYTE UNIX Benchmarks (Version 4.1.0) System -- Linux domU-12-31-39-0F-6A-54 2.6.21.7-2.fc8xen #1 SMP Fri Feb 15 12:39:36 EST 2008 i686 i686 i386 GNU/Linux Start Benchmark Run: Mon Jul 12 01:52:42 EDT 2010 1 interactive users. 01:52:42 up 4 min, 1 user, load average: 0.06, 0.15, 0.05 lrwxrwxrwx 1 root root 4 Dec 8 2009 /bin/sh -> bash /bin/sh: symbolic link to `bash' /dev/sda1 10321208 2261236 7535684 24% / Dhrystone 2 using register variables 9790577.1 lps (10.0 secs, 10 samples) Double-Precision Whetstone 2070.6 MWIPS (10.2 secs, 10 samples) System Call Overhead 826432.8 lps (10.0 secs, 10 samples) Pipe Throughput 180216.6 lps (10.0 secs, 10 samples) Pipe-based Context Switching 35821.3 lps (10.0 secs, 10 samples) Process Creation 3400.6 lps (30.0 secs, 3 samples) Execl Throughput 1598.5 lps (29.9 secs, 3 samples) File Read 1024 bufsize 2000 maxblocks 351687.0 KBps (30.0 secs, 3 samples) File Write 1024 bufsize 2000 maxblocks 252310.0 KBps (30.0 secs, 3 samples) File Copy 1024 bufsize 2000 maxblocks 140395.0 KBps (30.0 secs, 3 samples) File Read 256 bufsize 500 maxblocks 90709.0 KBps (30.0 secs, 3 samples) File Write 256 bufsize 500 maxblocks 66533.0 KBps (30.0 secs, 3 samples) File Copy 256 bufsize 500 maxblocks 36620.0 KBps (30.0 secs, 3 samples) File Read 4096 bufsize 8000 maxblocks 993044.0 KBps (30.0 secs, 3 samples) File Write 4096 bufsize 8000 maxblocks 827288.0 KBps (30.0 secs, 3 samples) File Copy 4096 bufsize 8000 maxblocks 428662.0 KBps (30.0 secs, 3 samples) Shell Scripts (1 concurrent) 3099.1 lpm (60.0 secs, 3 samples) Shell Scripts (8 concurrent) 645.9 lpm (60.0 secs, 3 samples) Shell Scripts (16 concurrent) 343.3 lpm (60.0 secs, 3 samples) Arithmetic Test (type = short) 2239232.1 lps (10.0 secs, 3 samples) Arithmetic Test (type = int) 2257100.6 lps (10.0 secs, 3 samples) Arithmetic Test (type = long) 2257519.2 lps (10.0 secs, 3 samples) Arithmetic Test (type = float) 991768.4 lps (10.0 secs, 3 samples) Arithmetic Test (type = double) 992230.0 lps (10.0 secs, 3 samples) Arithoh 0.0 lps (10.0 secs, 3 samples) C Compiler Throughput 1041.2 lpm (60.0 secs, 3 samples) Dc: sqrt(2) to 99 decimal places 42905.1 lpm (30.0 secs, 3 samples) Recursion Test--Tower of Hanoi 112156.8 lps (20.0 secs, 3 samples) INDEX VALUES TEST BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 9790577.1 839.0 Double-Precision Whetstone 55.0 2070.6 376.5 Execl Throughput 43.0 1598.5 371.7 File Copy 1024 bufsize 2000 maxblocks 3960.0 140395.0 354.5 File Copy 256 bufsize 500 maxblocks 1655.0 36620.0 221.3 File Copy 4096 bufsize 8000 maxblocks 5800.0 428662.0 739.1 Pipe Throughput 12440.0 180216.6 144.9 Pipe-based Context Switching 4000.0 35821.3 89.6 Process Creation 126.0 3400.6 269.9 Shell Scripts (8 concurrent) 6.0 645.9 1076.5 System Call Overhead 15000.0 826432.8 551.0 ========= FINAL SCORE 362.3
以下が、結果の一覧表です。
m1.small | c1.medium | m1.large | m1.xlarge | c1.xlarge | |
---|---|---|---|---|---|
Dhrystone 2 using register variables | 318.2 | 839 | 958.8 | 961.4 | 1109 |
Double-Precision Whetstone | 396.4 | 376.5 | 301.6 | 394.7 | 487.2 |
Execl Throughput | 196.7 | 371.7 | - | - | - |
File Copy 1024 bufsize 2000 maxblocks | 113.8 | 354.5 | 537.8 | 562.6 | 643.4 |
File Copy 256 bufsize 500 maxblocks | 74.9 | 221.3 | 348.5 | 361.1 | 415.8 |
File Copy 4096 bufsize 8000 maxblocks | 239.5 | 739.1 | 906 | 920.4 | 1101.7 |
Pipe Throughput | 48 | 144.9 | 259 | 270.3 | 314.1 |
Pipe-based Context Switching | 55 | 89.6 | 199.8 | 156.9 | 217 |
Process Creation | 111.1 | 269.9 | 272.2 | 281.1 | 320 |
Shell Scripts (8 concurrent) | 352.5 | 1076.5 | 1310.3 | 1637.7 | 1227.8 |
System Call Overhead | 447.2 | 551 | 226.8 | 243.7 | 283.4 |
m2.xlarge | m2.2xlarge | m2.4xlarge | cc1.4xlarge | |
---|---|---|---|---|
Dhrystone 2 using register variables | 1311.4 | 1313.4 | 1313 | 1438.6 |
Double-Precision Whetstone | 549.9 | 550.5 | 550.8 | 604 |
Execl Throughput | - | - | - | - |
File Copy 1024 bufsize 2000 maxblocks | 749.2 | 743.5 | 741.4 | 1645.2 |
File Copy 256 bufsize 500 maxblocks | 478.5 | 478.2 | 471.1 | 1049.4 |
File Copy 4096 bufsize 8000 maxblocks | 1512.2 | 1513.5 | 1495.8 | 2694.7 |
Pipe Throughput | 347.7 | 349.4 | 348.7 | 1059.8 |
Pipe-based Context Switching | 313.7 | 298.1 | 318.3 | - |
Process Creation | 377.6 | 377.5 | 375.7 | 225.3 |
Shell Scripts (8 concurrent) | 1826.7 | 2551.7 | 2333.8 | 738.3 |
System Call Overhead | 362.2 | 361.6 | 363.1 | 716.2 |
"cc1.4xlarge"は、計算処理もそうですが、ファイルコピーのパフォーマンスが素晴らしいですね。
あと、やはり、c1.medium(2.5ECU x 2)より、m1.large(2ECU x 2)の方が、CPUパワーが優れていそう(CPUの型番的には納得)なのと、m2.xlargeのI/Oパフォーマンスは"High"ではなかろうか?と思った次第。
最後に
長編となりましたが、全体的に、各インスタンスタイプやリージョンで、どの程度CPUやディスクI/Oのパフォーマンスで差異が出ているのかや、物理サーバとの比較結果を確認できたと思います。
考察については、各項目単位で述べてきたので、そちらをご参照ください。(まとめる体力がなくなったw)
それにしても、cc1.4xlargeのパフォーマンスが良かったのと、m2.xlargeのコストパフォーマンスが良さそうだ。コスパ的には、m1.smallが一番良いかもしれませんがね。
あと、ディスクI/Oパフォーマンスの結果を見て、これまで信頼性の観点から、EBSボリュームに設置しておけば、まず間違いないと思っていましたが、性能の観点からは、何でもかんでもEBSに置くものでもないな、と思いました。
この結果が、皆さんの何かの参考になれば。
あわせて読みたい
- Amazon EC2/S3を使ってみた - 7.Availability Zoneサービスで稼動ロケーションを指定する - 元RX-7乗りの適当な日々
- 別ゾーン(Zone)のサーバ間でのネットワークスループットなど
- Amazon EC2の「Cluster Compute Instances」を使ってみた(High Performance Computing向け) - 元RX-7乗りの適当な日々
- Cluster Compute Instanceについてのネットワークスループットなど
- Amazon EC2/S3/他がアジア(シンガポール)で利用可能になったのでレイテンシを計測してみた - 元RX-7乗りの適当な日々
- 各リージョンでのレイテンシの計測など
- Amazonが従量課金制のCDNサービス「Amazon CloudFront」を開始・・・したので試してみた - 元RX-7乗りの適当な日々
- Amazon CloudFrontでのネットワークスループットなど
まとめ
クラウドAMAZON EC2/S3のすべて (ITpro BOOKs)
- 作者: 並河祐貴,安達輝雄,ITpro/日経SYSTEMS
- 出版社/メーカー: 日経BP社
- 発売日: 2009/11/05
- メディア: 単行本
- 購入: 4人 クリック: 372回
- この商品を含むブログ (18件) を見る