PHPのテクメモ

PHPからすっかり離れている今日この頃。でも、それなりに楽しんでいる。

Postfixの設定で、main.cfを編集してPostfixを再起動。別のサーバからアクセスしてみて、relayをしないよう正しく設定されているかどうかチェックしてみた（いちおう毎度不正なrelayチェックができないかどうかちゃんと調べている・・・あたりまえだけど）。調べ方は簡単、telnetでアクセスして、適当にメールアドレスを指定して、rejectしてくれるかどうか調べるだけ。

しかし・・・そもそもPostfixからの応答がない。telnetの応答の後のPostfixの応答がない。

Trying 1.2.3.4…
Connected to example.com.
Escape character is ‘^]’.

コマンドを打っても返事がない。おいおい。どういうこと？。こんなんだったっけ。毎回うろ覚えなのでしばし考える。

ひょっとして、と思ってmain.cfで修正した箇所をコメントアウトしてPostfixを再起動し、再度コマンドを投げてみた。

Trying 1.2.3.4…
Connected to example.com.
Escape character is ‘^]’.
220 example.com ESMTP Postfix

あ、返事してるじゃん。ってことは、Postfixでmain.cfの記述を変更して、たとえその記述に間違った記述があったとしても、起動自体はできてしまうことがあるっていうことか。

あーやだやだ。

ここまでやってきてだいぶん理解が深まった。「apacheの子プロセスごとに持続的接続が管理される」かどうかを今一度調べないといけないが、仮にそうだとすると、世間のブログで書かれていることには結構嘘が多いことになる（嘘というかしったかぶり）。

例えばとあるブログで「同じホスト、ユーザ、パスワードのコネクションであれば前回のコネクションを使いまわす」という記述があるが、前述の論理にもとづけばこれは嘘。処理する子プロセスが違えば、当然コネクションなんて残っていない（初めからそんなものは存在しない）ので、最初から接続することになる。

何度かいろいろな処理があるうちに、たまたま、以前に使用したプロセスが処理を担当することになった時だけ、以前使用したコネクションが使いまわせることになる。

難しいことをさらっと書いてあるブログは多数存在するけれど、全てが信用できるわけではないって改めて理解した。

なんとなく持続的接続が理解できたような気がする。一部想像で話を進めてきた感はあるが、そこは改めて調べないといけない。で、ここまでの一連の流れの中で、設定すべき箇所を列挙しておくことにする。

apacheの設定

http://httpd.apache.org/docs/2.2/ja/mod/prefork.htm

• MaxClients
  最大同時リクエスト数を設定。でも当然apacheで使用できるメモリは決まっていて、個々の子プロセスで使用できるメモリ量は、子プロセス数が多いほど割り当てが少なくなる。だからちょうどよさそうなところを割り当てる必要あり。 preforkの場合は子プロセス数に相当するがworkerで設定したapacheでは、この値はスレッド数に相当することに注意。
  値を増やす際はServerLimit値も増やすこと。
• ServerLimit
  preforkの場合はMaxClientsと同じ値を設定する。
• StartServers
  apache（親プロセス）起動時に起動させる子プロセスの数。preforkならデフォルト5。
• MinSpareServers
  アイドル状態にある子プロセスの最小値。つまり常にいくつの子プロセスを待機させておくか。実際の待機数がここで設定した値よりも小さくなると、親プロセスが最大1秒に1個の割合で新しい子プロセスを生成する。
• MaxSpareServers
  アイドル状態にある子プロセスの最大値。待機中の子プロセスがここで設定した値よりも多い場合は破棄される。例えば一時的にリクエストが増えた場合はそれに応じて子プロセスが起動されるが、リクエストがなくなると必然的に子プロセスが待機状態となる。子プロセスが残っているということはその分メモリを使用している（他にも使っていると思う）ことになるので、必要な分は残し、不要な部分は破棄する。
• MaxRequestsPerChild
  子プロセスの処理回数の上限。デフォルトは1000。
  子プロセスは基本的に処理状態と待機状態を繰り返す。ここで設定した値を最大処理数として何度でも処理を実行する。しかしお行儀の悪いPHPプログラムとかその他の原因でメモリリークを引き起こすことがある。子プロセスに割り当てられたメモリを一度に食いきってしまうようなことがあると、その子プロセスは落ちるから、当該アクセスに限りエラーとなるが、少しずつリークした場合、当然その子プロセスで使用できる メモリの量が減る。そうしてメモリリークがたまると、結局どこかで落ちてしまう。ここで値を設定しておくと、自動的に子プロセスが再起動されるわけで、メモリリークも解消される。
  いちおうこのディレクティブはKeepAliveディレクティブにも関連するらしいが、それはまた後日調べることにする。

PHPの設定（以前にも書いたけどおさらい）

http://www.php.net/manual/ja/mysql.configuration.php

• mysql.allow_persistent
  持続的接続を可能にするか否か 。デフォルト1（接続可能）。
• mysql.max_persistent
  プロセスごとの持続的MySQL接続の最大数。デフォルト-1（無制限）。
• mysql.max_links
  プロセスごとの接続最大数。デフォルト-1（無制限）。
• mysql.connect_timeout
  タイムアウト時間。デフォルト60（単位は秒）。接続しようと試みて、ここで指定した時間を過ぎても応答が帰ってこなかったらエラー。最初に接続を確立する際（connect）や、SQLを投げた際に結果が返ってくるまでにかかる時間で最大どのくらい待ってやるか、ということ。

あー、よく調べた。一つ賢くなった。

いちおうapacheがprefolkである（もしくは1.3系である）という前提で調査を進めた。apacheのマニュアルを見る。

http://httpd.apache.org/docs/2.2/ja/mod/prefork.html

一つのコントロールプロセスが、コネクションに対してlistenして、しかるべき時に応答する子プロセスを起動します。Apacheは常に幾つかのスペアかアイドルなサーバプロセスを維持していて、それらは入ってきたリクエストに応答できるように待機しています。このようにしてクライアントは、リクエストが応答される前に、新しい子プロセスがforkされるのを待たなくてもよいようになっています。

つまり親プロセスがポートをlistenしていて、リクエストがあると子プロセスに処理をさせるといった具合。といっても子プロセスはリクエストのたびに生成（fork）されるのではなく、親プロセスによって、サーバ設定に従い、自動的に適切な数の子プロセスをforkしたりkill（破棄）したりする。

持続的接続とは関係ないけれど、PHPに関連する部分を一つ見つけた。

通常Unixでは親プロセスは80番ポートにバインドするためにrootで起動されますが、子プロセスやスレッドはもっと低い権限のユーザでApacheによって起動されます。UserとGroupディレクティブはApacheの子プロセスの権限を設定するのに用いられます。子プロセスはクライアントに送るコンテンツ全てを読めないといけませんが、可能な限り必要最小限の権限のみを持っているようにするべきです。

apacheはrootで起動するのに、なぜapacheで（PHPで）作成したファイルの所有者がapacheになるのか（httpd.confで設定したユーザになるのか）ということに関連している。apache自体（親プロセス）はrootが起動するのだが、その親プロセスが、より権限の小さい（httpd.confで設定された）ユーザやグループの権限で子プロセスを起動する。そういう権限で動作している子プロセスの元で動いているPHPなわけだから、PHPで作成したファイルの所有者はapacheになる。

今までは「httpd.conf」でUserとGroupで設定するから、と単純に思っていたけど、動作を紐解くとそういう原理になっていたわけか。意外と面白いかも。

持続的接続はapacheの子プロセスとの関連性が深い。だからapacheを理解することも必要だ。ということでマニュアルに目を通してみる。

目を通していると昔（サーバ管理をしていた頃）の記憶がちょっとだけよみがえる。PHPのマニュアルとか探すとその記述を見つけた。

http://www.php.net/manual/ja/faq.installation.php

PHPはグルー(糊)です。このグルーは、多くのサードパーティ製のライブラリをくっつけることによりクールなWebアプリケーションを構築するために使用され、直観的で簡単に習得できる言語インターフェイスにより、一つの整合性のある実体として見せることができます。PHPの柔軟性と力は、プラットフォームの安定性と堅牢性に基づいています。グルーによる結合をするためには、OSやWebサーバ、サードパーティ製のライブラリを必要とします。これらの一つの機能が停止した場合、PHPは問題を特定し、速やかに修正する手段を必要とします。実行スレッドを完全に分離しなかったり、メモリセグメントを完全に分離しなかったり、各リクエストで使用される強力なサンドボックスを有さないことで、基本的なフレームワークをより複雑なものにした場合、PHPのシステムに弱点が生まれます。

これは「なぜ、Apache2のマルチスレッドMPMモード（worker）を実運用環境で使用するべきではないのですか?」で記載されている文章。つまり（多分）、モジュール版のPHPを使用する場合はマルチスレッドMPMモードではなくMPM preforkモード（1.3系と同等）で使用しなさい、という意味に取れる。スレッドセーフではない、ってことかな。

マルチスレッドだと、処理の単位はスレッド（だと思う）。workerの場合、スレッドは子プロセスが複数のスレッドを管理しているわけで、子プロセス単位で持続的接続が共有されていると仮定すると、同じ子プロセス内の別のスレッドで同時に別々のリクエストを処理した場合、明らかに問題が出そうだ。こういうことなのかな。

ということで、まず、PHPはpreforkなapacheで動作させないといけないのだろう。

実際調べてみると、Debianやubuntuではapacheのパッケージはapache2-mpm-workerとapache2-mpm-preforkという別々のパッケージがあり、事前にworker版がインストールされていると、mod_phpをインストールする際に、それを削除してprefork版をインストールするようだ。Vineではパッケージこそ分かれていないけど、そもそもworkerで設定されているとPHPが動かないようだ。

そういうことを考えれば、おそらく出回っているサーバ（Linux系）は、ほとんどがpreforkで動作していると思ってよさそうだ。