NFSサーバ改善後の性能比較

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倍の性能向上ができました。

性能限界の原因となっているボトルネックを特定し、ピンポイントでチューニングができると大きな成果を上げることが可能です。

具体的な進め方が気になる方は、「負荷テストのすすめかた」をご覧ください。

ディーネットでは、負荷テストに関するお問い合わせも受け付けておりますので、お気軽にご相談ください。

コメントは受け付けていません。