大規模サイトの性能改善作業とは、どういうものなのか――。リクルートの中古車情報サイト「カーセンサーnet」を全面リニューアルした体験を基に、その実態をレポートする。第1回、第2回はミドルウエアのチューニングを行った。後半はLinuxカーネルに原因があると判明するまでの調査に進む。様々なツールを組み合わせて追跡していった。
中古車情報サイト「カーセンサーnet」の性能試験が本格的に始まって10日目。試験の開始当初は、ブラウザーの表示に10秒もかかるなど目標性能に遠く及ばなかった。しかし前回までで紹介したように、ファイル共有システム「NFS」の設定変更、Webサーバー「Apache」のパラメーター修正、PHPアプリケーションの見直しによって、性能は劇的に向上した。
リクルート入社3年目の私は、今回の性能検証プロジェクトのリーダーとして、得意分野を持つチームメンバーと一緒に対策を進めていた。カットオーバーまで、まだ1カ月以上ある状況で、それほど焦りは感じていない。何としてもやり遂げる、という当初の決意も揺るぎはなかった。
3つの対策によって、レスポンスタイムは2秒台、スループットは当初の4PV（ページビュー）/秒から40PV/秒近くにまで改善した。レスポンスタイムは目標性能が2~3秒なのでギリギリ合格点。スループットは目標性能の70PV/秒まで、もう1歩というところだ。さらに改善を重ねていけば、うまくいくのではないかと期待していた。
どうしても性能が伸びない
ところがその後、性能の改善が見られない状況が続くことになる。日に日に焦りが高まっていった。
まず、これまで進めてきたPHPのキャッシュ機構「APC」（Alternative PHP Cache）のチューニングを継続することにした。キャッシュするファイルを絞り込む「apc.filters」や、ファイル更新のチェックを省く「apc.stat」を試したり、APC以外のキャッシュ機構（xcacheなど）に変更してみたりしたが、ほとんど性能は改善しなかった。
どうやら、PHP周りに性能劣化の原因はないようだ。次にどこを探ればよいかと考えたが、1つ気になっていることがあった。目標の70PV/秒といった高い負荷をかけると、CPU使用率が高まり、中でもOS（カーネル）が使う「SYS」が増える点である。前回実施した試験でも、CPU使用率が70％のうち、SYSが40％、アプリケーションが使う「USR」が30％だった。SYSが高いのは、システムコールなどカーネルの処理が多いことを意味する。
CPU使用率が上昇していく様子を詳しく調べた（図1）。システムのスループットが35PV/秒を超えた辺りで、CPU使用率のSYSだけが上昇していく。それが原因でスループットが頭打ちになっているようだった。
CPU使用率が高く、SYSの割合が高い。その原因を調べるには、カーネル内部の処理を調べた方がよさそうだ。そこでアプリケーションとカーネルを含め、システム全体の「プロファイリング」を行うツール「OProfile」に着目した。プロファイリングとは、システムの性能を解析するため、関数呼び出しの頻度やそれにかかる時間など、プログラム実行時の様々な情報を計測する作業だ。
OProfileは、Linuxシステム向けのプロファイラー。「どの関数やどのライブラリが、どれくらいのCPUを使用しているのか」を調査できるツールで、システムのボトルネック特定に役立つ。計測対象のプログラムに対して何か処理を付加する必要がなく、利用時のオーバーヘッドが小さい。このため、稼働中のシステムに与える影響を最小限にしてプロファイリングを行える。
