Multi-threaded app does not scale-up on Amazon EC2

by syoyo

Based on yukoba‘s and my investigation, we’ve found that multi-threaded app does not scale-up on Amazon EC2.

For example, lucille renderer is multi-threaded app and scales well on the number of cores(threads) in general, but when running lucille on EC2 it no longer scales well on the number of threads(virtual cores).

I’ve executed lucille on xlarge instance(8 virtual cores) and got the following result.


Running lucille on xlarge instance
===================================
threads : rendering time(less is better)
1       : 41 sec
4       : 41 sec  <- Keep your eyes here!
8       : 21 sec

Note that the rendering time is same for 1 threaded version and 4 threaded version!

This is due to that Amazon EC2’s virtual environment does not attach each thread to each cores. For example there’s a situation that 2 thread is attached to 1 (virtual) core even though there’s 2 (virtual) cores.

I don’t know this is the problem of EC2. It might be the problem of virtual environment or linux kernels running on the virtual environment, but who knows…

Solution 1

yukoba found a simple workaround to scale-up multi-threaded app on EC2: Use nice -n -20 to the multi-threaded process.

With “nice -n -20”, the rendering time on EC2 was improved as follows.


Running lucille on xlarge instance with nice -n -20
=====================================================
threads : rendering time
1       : 41 sec
4       : 21 sec   <- improved!
8       : 15 sec   <- improved!

Solution 2

Another solution is “Don’t use threaded app, run app with multi-process fashion”.

i.e. For 8 (virtual) core machines, run 8 process of the app at a time.
It scale-ups well on Amazon EC2, but notice that it requires 8 times more memory!

[Ja]

ちょっと前に yokoba さんに指摘されて分かった、Amazon EC2 ではマルチスレッドアプリがコア数に比例してスケールしないという問題.
xlarge で 8 cores 使って, マルチスレッドだから 8 倍高速に処理できる!
と思っていたら、実は実質 4 cores しか使われていなくて無駄に課金されているという状況になったりしてしまいます.

これは EC2 のせいなのか、仮想環境そのものの制約から来る問題なのか、よく分かりません.
ひとまずは、マルチスレッドアプリを動かすときは気をつけましょうねということ.
yokoba さんが発見した nice 値をいじるで改善も見込めますが、本質的な解決策ではありません.

まあ EC2 とかのクラウドコンピューティングは基本的に scale-out の技術なので、
ギョーカイ的には、マルチスレッドじゃなくてマルチプロセスでやれよ、という方向性なのかもしれません.

ただ CG の場合はなるべく一枚の絵を高速に処理したいとか、
テクスチャやジオメトリをグローバルにアクセスできるほうがプログラム記述が楽だとかで、
マルチスレッドのほうがいいというのがあるんですよね.
それにマルチプロセスだと何も考えないとプロセス数ぶんのメモリが必要になりますし.

EC2 でクラウド計算だ!と言っても、hadoop とか web サーバがどうとかで、マルチスレッドアプリを動かすというネタはあまり聞きませんね. とくに CG 系のレンダリングなどの実務的な数値計算を EC2 で多量に効率的に行うときのノウハウはまったく無い模様.

一応 Render rocket という EC2 などでクラウドレンダリングするサービスがありますが、今一何やっているかは不明です.
MR とかをレンダラに選べるようですが、単に MR をボリュームライセンスで走らせているだけみたいなので、
EC2 にレンダラを最適化させてなにかやるということはしていなさそう.

RSL コンパイラ作成の時も思いましたが、CG 系側の要求はその分野のひとたちとの要求とはまた違ったものとなっていて、既存研究や既存のノウハウはあまり参考になりません.

そんなわけで、自分たちでリサーチして、実験して、ノウハウ得て、という感じで道を切り開いて行かなければならない亊が最近とても多いと感じています.しかし毎回毎回そんなことをするのも時間の無駄だと思うので、なんとかもっと効率的に問題 -> 解決のステップを達成できる方法はないものだろうかとも思っています.

関連

CPU performance of Amazon EC2 instances
http://lucille.atso-net.jp/blog/?p=659

Advertisements