チューニング

パフォーマンスチューニングというのも非常に重要な問題だ。黒魔術のようなかんじもしなくもないが、ヨタ話をいろいろ書いてみる。

性能の問題が表面化した場合、やみくもにパラメータをいじくりまわして問題を悪化させてしまう場合があるが、そーゆーことは避けたい。

何が問題なのか、定量的なゴールを明確化しないと、単なる感覚論になってしまって不毛な時間をついやすことになるので注意が必要である。

パフォーマンスチューニングの参考書はいろいろあると思うので適宜みつけだしてほしいが定番のこれはというのは、あるようでいてよくわからない。データベースのチューニングという題材での書籍はいろいろあるがいかんせん製品特有のTipsにかたよったものが多くてあまり汎用性がなかったりする。Oracleのパラメータを勉強するというのはそれはそれで必要なのだけど、わたしが目指しているものとちょっと違う。

ここでは一般的なアプリケーションのチューニングくらいの軽いノリのお話をする。

チューニングするくらいだから性能に満足していないという前提であるが、性能に特に不満がないのなら無理をしてチューニングする必要はない(当たり前だけど)。

性能とはここでは速度の事を言うことにするが、それ以外でもメモリ消費量だとか、ディスク消費量だとか別の次元でのチューニングというのもありえる。

CPU、IO、メモリなどはCPU時間、IO時間などを計測すれば、どこがボトルネックになっているかわかる。ロック競合の場合、CPUやIOはまだまだ余裕があるのにスループットが出ないなどの現象がでたりする。

いずれにせよ現状を正確に理解することが第一歩になる。

CPUボトルネックの場合、アルゴリズム、データ構造の改良などが必要になるが、そのまえに定量的な測定がかかせない。

速度を計測する基本は、時計である。実行にどれだけかかったかを計測する。それこそストップウオッチからはじまって、Linuxでは time コマンドを利用したりする。アプリケーションからであればgettimeofday()なんかを利用する。もっと精度をほしければTSC(time stamp counter)を利用するとよい。

実行プロファイルをとる。

linuxの場合oprofileが利用できるので、それを使おう。

ユメのチカラでは下記のエントリーが参考になる。

Rubyのプロファイリング
http://blog.miraclelinux.com/yume/2006/10/ruby_0b0e.html

実際にrubyの実装を題材にoprofileで計測し、ボトルネックを発見した事例を示している。

コードを読むな、理解しろ
http://blog.miraclelinux.com/yume/2006/10/post_e3d6.html

上記の性能チューニングのお話のまとめである。パッチの作り方も含めて事例を示している。ボトルネックを発見できれば、比較的簡単に解決策は見つかる。

もうすこし本格的なカーネルチューニングは以下である。

Linux Kernel 2.6.18とCache Pollution Aware Patch
http://blog.miraclelinux.com/yume/2006/09/linux_kernel_26_2c2c.html

2.6.18に採用されたカーネルパッチは下記のプロジェクトで作ったのだが、iozoneというベンチマークを実施し、oprofileでCPUキャッシュミスを計測した。そのボトルネックの部分についてカーネルパッチを作成し、効果を検証した。

キャッシュミスを発見するのはoprofileを利用すれば簡単にできる。ただ、その現象を解決するカーネルパッチの実装は(自分にとっては)簡単ではなかったが、パターンを発見したので今後同様の現象であれば、同じ方式で解決できる。

詳細については下記の報告書を参照されたい。

2005年度オープンソースソフトウェア活用基盤整備事業
「OSS性能・信頼性評価／障害解析ツール開発」
OS層
〜CPUスケーラビリティ評価編〜OS-cpu.pdfをダウンロード