microインスタンスはlimitかけると大きくパフォーマンスが向上する(※再追記あり)
※2014/07/02 T2インスタンスタイプとの比較 を追記しました。
※2014/03/13 他インスタンスタイプとの比較/m3.mediumの検証 を追記しました。
こちらの記事の二番煎じです。
cgroupで、お手軽CPU使用率制限
なるほど。
リソースにLimitかけるとstealを防げるためパフォーマンスも上がるというわけですね。
どのくらい変わるのか実験してみました。
cgroup前準備
sudo yum install libcgroup sudo chkconfig cgconfig on sudo service cgconfig start
cgroup設定
上記参考URLとほぼ同じ設定です。
実行時はcpu.cfs_quota_usを変動させて比較してみました。
sudo vi /etc/cgconfig.conf # 以下を追加 group limittest { cpu { cpu.cfs_quota_us = 250000; # Max25% cpu.cfs_period_us = 1000000; } cpuacct { } } # 変更後はリスタート sudo service cgconfig restart
定常的に使う時は、memory.limit_in_bytes なども設定して
メモリもlimitかけると良いかもしれません。
比較コマンド
perlのビルドの時間を比較してみました。
リミットなしバージョン
time perlbrew install perl-5.18.2
リミットありバージョン
time cgexec -g cpu:limittest /root/perl5/perlbrew/bin/perlbrew install perl-5.18.2
結果
- | real | user | sys |
---|---|---|---|
リミットなし | 186m59.721s | 127m54.352s | 51m52.487s |
リミットあり(Max25%) | 90m8.645s | 15m4.317s | 5m31.501s |
リミットあり(Max30%) | 75m3.421s | 15m1.468s | 5m24.844s |
リミットあり(Max40%) | 87m26.738s | 23m40.645s | 8m50.737s |
リミット無しでsteal発生しまくりの時はおよそ3時間かかっていたのが、
リミットあり(Max30%)だと1時間15分ほど。2倍以上速い!!
※以下引用
いくつかの調査をした結果,
Amazon EC2 Microインスタンスの挙動について
・直近の100秒のCPU使用率が20%を超えている場合は低速モードに移行する
・低速モードはCPU使用率の97%が使えない状態(steal)になる
とあるので、20%ギリギリ超えるくらいがちょうどいいかなと予想していましたが
実際には30%が一番パフォーマンスが良かったです*1
vmstatでstealの値も見ていたんですが、
Max40%だと結構stealが発生していて、
Max30%の場合ごくごくわずかにstealが発生するくらいでした。
常にCPUMaxをつかう処理があるわけではないと思うので、
20%よりも少しばかり高めに設定したほうが
効率が良いのかもしれませんね。
まとめ
cgroupで制限するとmicroインスタンスでは大幅なパフォーマンス向上が見られました。
大きいビルドなど行うときには必須ではないでしょうか!
※追記 他インスタンスタイプとの比較
smallとの比較があったらよいのでは、というコメントを頂いたので
ついでにインスタンスタイプ別に比較してみました。
m1.smallだけでなく、グループ毎の下位クラスも一緒に比較してみました。
- | real | user | sys |
---|---|---|---|
t1.microリミットありver | 75m3.421s | 15m1.468s | 5m24.844s |
m1.small | 46m3.623s | 29m54.188s | 10m54.853s |
m1.medium | 25m33.974s | 15m17.969s | 5m0.599s |
m3.medium | 31m42.804s | 18m45.818s | 7m47.473s |
c1.medium | 25m1.527s | 15m16.129s | 5m34.785s |
c3.large | 16m41.832s | 9m31.712s | 3m25.633s |
c3は予想通りの早さですね。
他のインスタンスも軒並み予想通りですが、一つだけ気になる結果があります。
m3.mediumインスタンスです。
m1.mediumとm3.medium
公式のインスタンスタイプを見ると
以下のようになっています。
- | ecu | vcpu |
---|---|---|
m1.medium | 2 | 1 |
m3.medium | 3 | 1 |
あれれ、数値上はm3.mediumの方が良さそうですね*2。
なぜm1.mediumの方が速いのでしょうか?
ビルド時のスナップショット
m3.mediumのビルド時のvmstatのスナップショットです。
stealが40-50%ほど発生しています。
m1.mediumはというと、stealの発生はありませんでした。
予想:CPU共有タイプ?
公式ドキュメントからは確認出来なかったのですが、
おそらくm3.mediumもm1.smallと同じように
「CPU共有型なのではないか」と予想しました。
詳しくは以下のブログをご覧頂くと良いです。
AmazonEC2 m1.smallのCPU配分
http://php6.jp/linux/2012/01/20/amazonec2-m1-small/
vmstatの推移がm1.smallとm3.mediumで同じような挙動をしているので
ほぼ間違いないのではないかと思います。
m3.largeも試してみる
本当は上記インスタンスだけ比較して終わろうと思ったのですが、
m3のグレードを一つ上げたらstealしなくなるか、を確認してみました。
- | real | user | sys |
---|---|---|---|
m3.large | 17m1.667s | 10m1.062s | 3m21.857s |
ビルド時のスナップショット
stealが消え、ほぼ公式と同じような性能が出ているように見えます*3。
やはり、stealが発生するのはm3.mediumだけのようです。
追記:まとめ
単に性能比較して終わる予定だったのですが、
m3.mediumインスタンスで新たな発見がありました。
m1.mediumと比べて、
「m3.mediumの方が安いし性能もいいしこれでいいじゃんヒャッハー!!!」
と思っていましたが、mediumだけでみると「m1.mediumの方が速い」という結果でした。
ほげぇ。
匿名さん、コメントありがとうございました。
再追記:T2インスタンス
バーストありとバーストなしで追試しました。
バーストあり時は t2.micro/t2.small/t2.medium であまり変わらなかったので
どちらもt2.microの値です。
- | real | user | sys |
---|---|---|---|
t2.micro(バーストあり) | 14m46.383s | 8m53.064s | 0m26.884s |
t2.micro(ベースライン:10%) | -(※注1) | -(※注1) | -(※注1) |
バースト時にはc3インスタンスと遜色ないですね。
また、以下はt2.microのバーストあり時の残高クレジットです。
30-22で、およそ8クレ消費しているようですね。
※注1
【悲報】ベースラインビルド、なんと
2週間回し続けても一向に終わる気配がありませんでした!!!
(途中で強制終了しました)
もしかしたら実測としてはベースラインを大きく下回っているのかも…
*1:途中ネットワークアクセスなども発生していたり、というのもあると思います
*2:自分もこの辺りの性能比較を過去記事に書いています http://d.hatena.ne.jp/toritori0318/20140203/1391445479
*3:c3.largeと比較して