ロードバランサの件 その後５くらい

日経Linuxの2011年11月号と12月号でロードバランサ＋NFS＋PHP(各サーバOSはRHEL5)のような構成の連載があって、まさに自分が同じようなことにハマッて苦悩していたなと思って読んでいました。
自分がはまったこととあわせて、ポイントをまとめると.....

ポイント

• NFSにPHPプログラムの実体を置かない

NFSサーバに置くのは静的なコンテンツ(更新レートが低い画像などのファイル)を蓄積していくのみです。
→これはパフォーマンステストを行ってみればわかります。NFSサーバにI/Oが激しい状態となりとにかく遅いです。
→遅くならないのであればNFSサーバにPHPのスクリプトを共有させたいのですが..。なにかよりよい解決方法があれば良いのですけど。

• NFSでPHPのセッションを共有する場合、session.gcを使用しない

このページhttp://php.y-110.net/wiki/index.php?%A5%B5%A1%BC%A5%D0%BF%C7%C3%C7%A1%A7vmstatが非常に参考になる。php.iniの「session.gc_probability = 0」とし、セッションファイル(sess_*)はtmpwatchとかで定期的に消すようにする。

→これがAPサーバ全体のパフォーマンスを落とす原因だったとはなかなか気づけない件
→症状としては、PHPセッションを使用しているシステムの場合、動作が微妙に遅くなる。クリックして３秒とかかかったりそれ以上待たされたりといった感じでレスポンスが悪い。
→いろいろ試行錯誤してロードバランサのソフトをnginxとかhaproxyとかに変えたりSSL化にstunnelとかsquidを使ってみたけれど状況は変わらずでしたが、まさかphpのセッション管理でそれほど遅くなるとはね。

• PHPのセッションファイル(sess_*)をtmpfs上に保存させる

応用して、NFS上のPHPセッションファイル共有エリアをネイティブなDisk上ではなく、tmpfsのメモリ上に置くようにしてみました。システムの規模にもよりますが、256MB程度あればいいのでは？
(※tmpfsが満杯になると動作があやしい状態になるので空き容量には余裕を持っておいた方が良いです。)

ともかく、ロードバランサやNFSなどシステムが大きくなるといろいろ問題が発生して切り分けが難しくなります。なんでも一筋縄ではいかないです.....NFSの代替案にiSCSIで同じことできないかと試してみたことがあります。ただiscsiだと複数台のAPサーバからアクセスすると書き込みの整合性取れなくなっておかしくなってしまいまともに動かなかったのでやはり手段はNFSとなった経緯があります。iscsiはサーバと1対1接続になるんですかね。よく仕様がわかってないですが..