3コアのCPUに換装したDBサーバーであるが、重いクエリを発行した場合、複数コアを有効に使っていないことに気付く。

まぁ、これは換装前(2コア)の時点で、既に分かっていたことであるが。

# 今回は余っていたCPUを転用しただけで、費用は掛かっていないのだ。

実際にモニターしてみると...



グラフの全範囲でCPU占有率は高いものの、100%に達しているのは3つあるうちの1コアだけである。

しかも、ほとんどが橙色(CPU1)であり、たまに赤色(CPU2)と緑色(CPU3)が「登板」するものの、それらはごく短時間。

CPU1がMAX(100%)まで使われている間、CPU2とCPU3が40%以下で休んでいるなら、CPU2とCPU3もMAXまで使い、処理時間を短くしろ、と、普通は考えるだろう。

同じハード構成で、別のパターン。



CPUの入れ替わりは先の場合に比べ頻繁になってはいるが、100%に達しているのは1つだけだ。

ッたく、他は何をやってるんだ！

これなら3コアを雇用する意味はない！

解雇(クビ)だ！クビ！

と、実世界ではなりそう(マジレスするとなってるｗ)が、これは、1つのクエリを複数のコアで処理することができないため。

また、本件のMySQLのバージョンは5.1.73であり、古いことも影響している。

まぁ、最近はシングルコアを探すのが難しく、最安のCeleronでもDualコアなので、あまり神経質になることもなかろう。

複数クエリや複数使用となってくると、複数コアのメリットが生きてくる。

今回は業務(つまり社内)用途であり、同時利用者数がそれほど多くないので、複数コアを上手く生かせないが、これが一般公開WEBサービス等で、利用者が非常に多い場合は、複数コアを生かせるだろう。

サーバーの場合、ディスクやメモリーは分かりやすい(簡単)であるが、CPUの場合は意外と複雑なのだ。

クライアント端末の場合は、CPU不可が高い原因は比較的簡単に掴めるし、用途が分かればCPU能力が必要かは判断できる(エンコードであればCPU等)が、サーバーの場合は用途だけでなく、その細部を探らなければならない。

いずれにしても今は安いので、それなりの用途(大規模ではない)であれば、CPUもメモリーもディスクもそれなりのもので十分。

それでも遅いなら、DBの設計やSQL文、indexが有効に使用されているか等を見直すことだ。

あとは、工夫。

最終結果の表示が遅いなら、最終結果をDBに格納しておき、それを出せば軽くなる。

少しでも速く ━

開発をしているとそういう気になってしまい、CPUを変えたら？と思うが、そういう場合、替えても大して速くならない(泣)

その後、基本に戻るのだが、そのような考えが「定期的に」出てくるので困ったものだ(笑)

タグ ：

#MySQL

#CPU

#複数コア

#遅い

#問題