2011年01月04日　(2011/01/04 23:59 )

Core i7-875K サーバでMySQL処理実験、リモート処理、パラレル処理

　カテゴリ : デジモノ　タグ :

■2010/12/26 [Core i7-875K で新サーバPC組み立て決意！すでに「発送済み」のパーツ一覧]
■2010/12/28 [Core i7-875Kで新サーバPC - パーツが届くも、CPUクーラーが別売り？！]
■2010/12/29 [高さ64mmのCPUクーラー「SHURIKEN rev.B」購入、でも高さはギリギリ！]
■2010/12/30 [Core i7-875Kで新サーバPC - OSのインストールもすんなり完了！]
　
CPUクーラーが別売りだったこともあって、ちょっと手間取った
Core i7-875K マシン のセットアップですが、その後の作業は至って
順調に進み、普通のサーバマシンとして使えるようになりました。
　

　
で、現在のWebサーバ機能を移行していきたいところなのですが、
なにぶん色々なものが詰まっていて、かつルータ側からWebアクセスを
転送する先を 1サーバ しか選べないため、サービスに分けて部分的に
移行していくのは難しいものがあります。3台あれば、1台をバランサに
するという手もあるのですが、いずれにせよ後々は1台構成に戻したい、
と思っているときにそういう複雑な構造にしたくはありません。
　
では今あるものを何1ついじらずに、丸々全部ドカッと移行すればいいじゃ
ないか、というお話なのですが、実は今のシステムはeucで動いていて、
この機会にこれを全部utf8に直したいと思っていたところだったのです。
　
そうはいっても全てのプログラムの校正（？）が終わるまで
新サーバが遊びっぱなしというのも勿体無いものですので、
何とか部分的に移行してけないかなと思案していました。
　
そこでちょっと思いついたのが、とりあえず DBだけ移行 するという案です。
あるサービスのプログラム部分をutf8に書き換えたら、そのサービスで
使っているDBだけ新サーバのほうを使うようにすれば、段階的に移行
できるかもしれないと思ったのでした。
　
で、ちょっと実験してみます。
　
　環境1:　Core2Duo E6700 (2.66GHz, 2 core) + MySQL 4.1
　環境2:　Core i7-865K (2.93GHz, 4 core) + MySQL 5.0
　
この環境に数百行の小サイズのデータを入れたテーブルを入れ、
INDEXで1発で引けるクエリを1万回投げてみるということをしてみます。
実際には単体の処理自体はすぐにキャッシュに乗ってしまいますので、
これは 通信コスト がほとんどを占める実験になります。

実行時間(1万回)	トータル	1回あたり
環境1: Core2Duo E6700	6秒	0.6msec/回
環境2: Core i7-865K	4秒	0.4msec/回

こんな感じになりました。あれ、1.5倍 程度？と思うのですが、
これはシングルスレッドの実験になりますのでこの程度の結果になりました。
　
ここで、環境1から環境2のDBをリモートで繋いで利用する、という
タイプを実験してみます。
　
　環境3:　環境1から環境2のDBに リモート接続 する
　
するとこうなりました。

実行時間(1万回)	トータル	1回あたり
環境1: Core2Duo E6700	6秒	0.6msec/回
環境2: Core i7-865K	4秒	0.4msec/回
環境3: 環境1⇒環境2	127秒	12.7msec/回

いやいやいや！ 何でこんなに遅い んですか！！
　
これではいくら何でも使い物になりません。実はこの実験を始めたのも、
最初1つめのサービスを仮移行してみたときに異常に遅くて参ってしまって、
原因究明のために実験をしたという経緯がありました。
　
そこで原因を調査したところ、どうもMySQLは ホスト名逆引き がONになっていると
それだけでロスが発生する、ということを知りました。mysqldのオプションで
--skip-name-resolve を指定するとこれをスキップできるようになります。
(そのかわりmysqlユーザ登録が直IP指定込みになっていないと接続できなくなります)
　
　環境3':　環境1から環境2のDBにリモート接続する(--skip-name-resolve)

実行時間(1万回)	トータル	1回あたり
環境1: Core2Duo E6700	6秒	0.6msec/回
環境2: Core i7-865K	4秒	0.4msec/回
環境3': 環境1⇒環境2	12秒	1.2msec/回

・・・一気に 10分の1 に縮まりました(;´Д`) なんとうことだ。
　
これでもローカルから叩くのとは3倍の差があるのですが、それはこの実験が
中身のほとんどないコネクション負荷ばかりが占める実験だということも
影響していますので、実際にSQL処理自体が多くを占めるようなクエリであれば
もっと差はなくなっていくでしょう。
　
これだったら移行期にはこの形で分担しても良いかなとちょっと思っています。
　
　
さて、最後は パラレル で接続した場合の性能です。環境3(リモート)は
もう置いておくとして、環境1(Core2Duo E6700)、環境2(Core i7-875K)、
それぞれのローカル環境でどのくらい違いが出るか試してみましょう。
　
前知識として、Core2Duo E6700は2コアでHyper-Threading未対応ですので、
論理コアは2、Core i7-875Kは4コアでHyper-Threadingあり、つまり
論理コアは8 ということになります。
　

　
まずは8パラレル。

実行時間(1万回)	トータル	1回あたり
環境1: Core2Duo E6700	24秒	2.4msec/回
環境2: Core i7-865K	7秒	0.7msec/回

続いて16パラレルです。

実行時間(1万回)	トータル	1回あたり
環境1: Core2Duo E6700	47秒	4.7msec/回
環境2: Core i7-865K	12秒	1.2msec/回

シングルスレッドだったときには1.5倍しか差がなかったものが、
8パラレル時だと 3倍、16パラレル時だと 4倍の性能差が出てきます。
これくらいの数字を出してくれると、新しいマシンを買った甲斐がある
というものです。
　
この数字をみても、やっぱりマルチコアというのはそもそもサーバ向け
だなぁという気がしないでもありません。個人のデスクトップでも、
OSのプロセス等が裏で動いていますので、マルチコアが無意味ということは
全然ないのですが、それでも 本気で複数コアが回る のはエンコードなどの
特殊用途のときが多く、通常はなかなかこういう大量処理をパラレルに
捌ける機会というのにはめぐり合えません。
　
この論理8コアがフルに回転しっぱなしになるかと思うと胸熱です（おい）。