php.ini_チューニング

JITAKU_SVR_Wiki

php.ini †

WEB + DB連携 †

WEB(apache + php)サーバ + DB(postgresql)サーバ 構成時に起きていた事象

WEBサーバへのクライアントからのセッションが終了しているにも関わらず、
DBへのセッション(postgresqlサーバでpsコマンドで確認するとidle)が残っている。

自分が予測していた動作と異なっていたので少し調査したところ、推測だが、以下のことが分かった。

pgsql.allow_persistent †

WEBサーバはDBサーバに対し、セッションを残し、そのセッションを使いまわそうとしている。
これは常に同じセッション内であれば当然新しくプロセスを産む必要がなくなり、パフォーマンスが良くなるからだと思われる。

普通に考えたらその通りで、むしろそうしてくれた方が都合が良い。

ただ、サービスの使い方によってはこのセッション維持は全く使わないことも多い。
例えば特定のユーザがDBに接続し、一度だけselect投げる。それでセッションが終了。

これを100回別々なところから接続される場合、セッションを残される方が困る。 残されたセッションがそのままになり、やがてDBのMaxConnectionに到達してしまう。

なぜこの現象が起きるかと言うと、php.iniの中に以下の設定項目があった。

pgsql.allow_persistent = On
※持続的接続を有効にする(デフォルト)

コメントしたとおり、接続を有効にしてしまっていた。

この設定は非常に大切だと思うので、使われるサービスによって検討すべき。

pgsql.max_persistent †

では、最大何本まで上記のセッションが生まれてしまうのか。
MaxConnectionまで到達させなければ良いのでは？

その設定もphp.iniの中に入っていた。

pgsql.max_persistent = -1
※持続的接続の最大数
  -1は無限を意味する(デフォルト)

結論 †

pgsql.allow_persistentとpgsql.max_persistentがデフォルトで死なないし、増え続ける設定になっていた。
なので負荷テストを行うとパンクしてしまう。

課題 †

では…なぜ通常(普段)はパンクしないのか？

httpd.confの設定 †

その答えは恐らくhttpd.confの中の以下のデフォルトのチューニングによると思われる。
(preforkの場合だけ通用？)

<IfModule prefork.c>
StartServers       8
MinSpareServers    5
MaxSpareServers   20
ServerLimit      256
MaxClients       256
MaxRequestsPerChild  4000
</IfModule>

幸か不幸か、デフォルトの設定では、MaxClientまでのプロセスの増え方は

MinSpareServers    5
MaxSpareServers   20

となっているため、上記のパターンに当てはまらないプロセスはkillされていく。