php-cgiプロセスのメモリ使用量は着実に増加しています


8

VPSにWebサーバーをセットアップしようとしています。私の問題は、ウェブサイトがまったくトラフィックを受信して​​いないにもかかわらず、php-cgiプロセスのメモリ使用量が時間とともに増加することです。(当面はファイアウォールの背後にあります)

VPSには360MB RAMがあります。私はDebian Lenny 32ビットとそのlighttpdおよびphp5-cgiパッケージを使用しています。いくつかの構成変更(以下にリスト)を除いて、私はDebianによるストックセットアップを使用しています。

ウェブサイトはDrupalに基づいています。Drupalのdevelモジュールを使用すると、PHPスクリプトのメモリ使用量は平均で20KB未満であり、8MBを超えることはありません。

以下は、出力の関連部分ですps aux

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
www-data 29871  0.0  1.7  54552  6368 ?        Ss   Aug12   0:00 /usr/bin/php-cgi
www-data 29873  0.0  7.4  65808 27468 ?        S    Aug12   0:00 /usr/bin/php-cgi
www-data 29874  0.0  3.7  55808 13736 ?        S    Aug12   0:00 /usr/bin/php-cgi
www-data 29875  0.0  4.3  58040 16204 ?        S    Aug12   0:00 /usr/bin/php-cgi
www-data 29876  0.0  4.4  57444 16288 ?        S    Aug12   0:00 /usr/bin/php-cgi
www-data 29877  0.0  1.7  54552  6368 ?        Ss   Aug12   0:00 /usr/bin/php-cgi
www-data 29879  0.0  9.6  67140 35684 ?        S    Aug12   0:26 /usr/bin/php-cgi
www-data 29880  0.0  6.6  59172 24492 ?        S    Aug12   0:23 /usr/bin/php-cgi
www-data 29881  0.0  7.1  59784 26388 ?        S    Aug12   0:22 /usr/bin/php-cgi
www-data 29882  0.0  7.4  60880 27440 ?        S    Aug12   0:23 /usr/bin/php-cgi
  • php-cgiがこれほど大きいのは普通ですか?
  • 設定に基づいてphp-cgiのメモリ使用量を推定することは可能ですか?
  • php-cgiプロセスのメモリ消費を削減するためのヒントはありますか?

既知のメモリリークのバグを検索しても、関連性はありませんでした。そして、デフォルトのDebianパッケージ/構成にそのような明らかなメモリリークがあったとしたら、私は驚くでしょう。同じホスト上の他のユーザーにはこの問題はありません。

これまでに行ったことはPHP_FCGI_MAX_REQUESTS、php-cgiプロセスが迅速にリサイクルされるように低い値に設定されています。を使用abして高負荷をシミュレートすると、これは非常にうまく機能します。プロセスは、10MBを超える前にすぐに停止します。ただし、低から中程度の負荷では、すべてのプロセスが着実に成長し(負荷分散のため)、それらのほとんどが同時に28MB +を消費し、私のVPSがスワップのリスクにさらされます。トラフィックがまったくない場合でも、プロセスは着実に成長していることに注意してください。

php-cgiプロセスの数を減らすことはできますが、これは修正よりも回避策のように感じます。php-cgiが通常このように成長した場合、私は驚かれます。

また、php-cgiプロセスのRSS総数を合計すると、次のようになります。

$ ps -C php-cgi -o rss= | awk '{s+=$1}END{print s/1024}'
195.738

ただし、free -m次の出力が表示されます。

             total       used       free     shared    buffers     cached
Mem:           360        351          8          0         33        190
-/+ buffers/cache:        127        232
Swap:          255          0        255
  • 何か不足していますか?使用されているメモリ(バッファなし)が、ホスト上のphp-cgiプロセスの常駐メモリの合計よりも低いのはなぜですか?

次のPHP拡張機能があります。

php5-cgi php5-common php5-curl php5-gd php5-mysql php5-xcache

xcache.size24Mに設定されています。以前は32Mでしたが、削減しても効果がありませんでした。xcache.var_size残りのプラグインはストック構成を使用しています。xcache管理ページは、xcacheが1MB未満しか使用していないことを示しています。

PHP memory_limitは32Mに設定されています。

これが私のFastCGI構成です。

fastcgi.server    = ( ".php" =>
  ((
    "bin-path" => "/usr/bin/php-cgi",
    "socket" => "/tmp/php.socket",
    "max-procs" => 2,
    "idle-timeout" => 20,
    "bin-environment" => (
      "PHP_FCGI_CHILDREN" => "4",
      "PHP_FCGI_MAX_REQUESTS" => "1000"
    ),
    "bin-copy-environment" => (
      "PATH", "SHELL", "USER"
    ),  
    "broken-scriptfilename" => "enable" 
  ))
)

lighttpd.confDebianに同梱されている在庫を多かれ少なかれ使用しています。

他に提供できるデータがあるかどうかをお知らせください。

どんな助けでもありがたいです。私はこれを何日間もトラブルシューティングしてきました。アイデアが足りなくなった。

回答:


2

var_sizeを小さくしてみてください。64MBの価値がある場合、数時間後には多くの交換が始まり、次の数時間後には完全にダウンしました。元の設定を32Mに保つようにしてください。多分これはあなたに役立つはずです-私たちの旅行サイトでも同じ問題がありましたXcacheはまだバグの多いソフトウェアです:(


1

最大リクエスト数の設定は正しい考えです。これは、メモリリークが発生したときにシステムRAMがいっぱいにならないようにする方法です。

私がお勧めすることの1つは、Apache + mod_phpに切り替えることです。メモリがリークすることなく機能する場合、問題はCGIに関連していることを意味します。mod_phpでリークが続く場合は、コードのどこかにメモリリークがある可能性があります。

あなたはDrupalを使っていると言いました。Drupalモジュールがインストールされていますか?Drupalの安定バージョンのコアにメモリリークがあるとは思えないので、問題はモジュールやその他のサードパーティのアドオンやカスタマイズで発生する可能性が最も高いです。


ご回答有難うございます。すべてのDrupalモジュールはよく知られており、develモジュールはDrupalでのメモリリークを報告しません。また、ヒットがない場合でもメモリリークが発生します。Apacheを試すことに関しては、これがアイデアがなくなったときの最後の手段として残しておきます。再度、感謝します。
ジョン

同じ問題が発生しています... PHP-CGIプロセスを使い終わったら、どうやってkillしますか?私はWordpressで同じ設定を使用しているだけで、256mibスライスがほぼ終了しています。
カイル

Nginxは両方のサーバーよりも小さく、PHPからのメモリリークがないため使用してください。Wordpressや他の大規模なサイトで使用されています。
Xeoncross


0

/etc/php5/apache2/conf.dから未使用のライブラリを削除します。おそらく、pdo.iniとpdo_mysq.iniまたはmysqli.iniは必要ありません

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.