NFSサーバは複数のサーバでファイル共有ができ便利な反面、IOが頻発する環境には適していません。NFSサーバがボトルネックになり、ローカルディスク環境へ移行した場合の性能比較をご紹介します。
ボトルネック
今回のケースでは、WEBサーバのCPU使用率の中でもSYSTEMの利用率がボトルネックとなっていました。SYSTEM使用率はカーネルの動作にて上昇します。静的コンテンツなどのアクセス数が多いWEBサーバなどでは、処理の切り替えが多発して上昇しやすい傾向になります。今回のケースでは、SYSTEMが50%と非常に高い値となっており、単純なアクセス数の問題ではなさそうでした。
PHPアプリケーション内に処理時間をログ出力するように改修していただき、問題箇所の特定をしていきます。その結果、特定のファイルを共通で読み込んでおり、そこで多くの時間がかかっていることが判明しました。処理時間が長くかかっていたのは、以外にも「require_once」が大量に発行されている箇所でした。
実際のスループットと平均応答速度の推移は次のようになりました。
チューニング前のスループットと平均応答速度
※グラフの見方は、「限界スループットの確認方法」を参照ください
チューニング内容
「require_once」では、指定されたファイルの読み込みが都度発生します。該当ファイルが配置されていたのはNFSサーバ上のマウント領域でした。そこで次のご提案を行い対応いただきました。
- PHPファイルはNFSサーバではなくローカル領域へ設置
- PHPファイルはlsyncdで同期を実施
性能比較
チューニングを実施しただき、2.5倍程度のスループット改善が見られました。SYSTEM使用率も50%から20%へダウンしています。
下のグラフはチューニング前後のスループットと平均応答速度を比較したものです。
チューニング前後のスループットと平均応答速度比較
まとめ
PHPの大量の「require_once」とNFSサーバがボトルネックとなる珍しいケースだと思います。NFSサーバからローカルディスクへ切り替えることで2.5倍の性能向上ができました。
性能限界の原因となっているボトルネックを特定し、ピンポイントでチューニングができると大きな成果を上げることが可能です。
具体的な進め方が気になる方は、「負荷テストのすすめかた」をご覧ください。
ディーネットでは、負荷テストに関するお問い合わせも受け付けておりますので、お気軽にご相談ください。