メモリリークの診断-許容メモリサイズ＃バイトが使い果たされました

私は恐ろしいエラーメッセージに遭遇しました。恐らく骨の折れる努力で、PHPはメモリを使い果たしました：

123行目のfile.phpで####バイトの許容メモリサイズを使い果たしました（####バイトを割り当てようとしました）

制限を増やす

あなたが何をしているかを知っていて、制限を増やしたい場合は、memory_limitを見てください：

ini_set('memory_limit', '16M');
ini_set('memory_limit', -1); // no limit

注意してください！あなたは症状ではなく問題を解決しているだけかもしれません！

リークの診断：

エラーメッセージは、メモリがリークしている、または不必要に蓄積されていると私が思うループのある行を指しています。memory_get_usage()各反復の最後にステートメントを出力しましたが、制限に達するまで数が徐々に増加しているのがわかります。

foreach ($users as $user) {
    $task = new Task;
    $task->run($user);
    unset($task); // Free the variable in an attempt to recover memory
    print memory_get_usage(true); // increases over time
}

この質問の目的のための最悪のスパゲッティコード想像がグローバルスコープのどこかに隠れていると仮定してみましょう$userかTask。

問題を見つけて修正するのに役立つツール、PHPのトリック、またはブードゥーのデバッグは何ですか？

PHPにはガベージコレクタがありません。参照カウントを使用してメモリを管理します。したがって、メモリリークの最も一般的な原因は、循環参照とグローバル変数です。フレームワークを使用している場合、それを見つけるためにトロールするコードがたくさんあると思います。最も簡単な方法は、選択的に呼び出しをmemory_get_usage行い、コードがリークする場所にそれを絞り込むことです。xdebugを使用して、コードのトレースを作成することもできます。実行トレースとを使用してコードを実行しshow_mem_deltaます。

サーバーでメモリを最も多く使用しているスクリプトを特定するために使用したトリックを次に示します。

次のスニペットをにあるファイルに保存します/usr/local/lib/php/strangecode_log_memory_usage.inc.php。

<?php
function strangecode_log_memory_usage()
{
    $site = '' == getenv('SERVER_NAME') ? getenv('SCRIPT_FILENAME') : getenv('SERVER_NAME');
    $url = $_SERVER['PHP_SELF'];
    $current = memory_get_usage();
    $peak = memory_get_peak_usage();
    error_log("$site current: $current peak: $peak $url\n", 3, '/var/log/httpd/php_memory_log');
}
register_shutdown_function('strangecode_log_memory_usage');

以下をhttpd.confに追加して使用します。

php_admin_value auto_prepend_file /usr/local/lib/php/strangecode_log_memory_usage.inc.php

次に、ログファイルを分析します。 /var/log/httpd/php_memory_log

touch /var/log/httpd/php_memory_log && chmod 666 /var/log/httpd/php_memory_logWebユーザーがログファイルに書き込む前に、必要になる場合があります。

以前のスクリプトで、私のforeachループの後でも、PHPがスコープ内のように「as」変数を維持することに気づきました。例えば、

foreach($users as $user){
  $user->doSomething();
}
var_dump($user); // would output the data from the last $user 

私がそれを見たので、将来のPHPバージョンがこれを修正したかどうかはわかりません。これが事実である場合、行のunset($user)後でdoSomething()それをメモリからクリアすることができます。YMMV。

PHPでメモリリークが発生する可能性のあるポイントがいくつかあります。

• PHP自体
• PHP拡張
• 使用するphpライブラリ
• あなたのphpコード

最初の3つを見つけて修正するのは、深いリバースエンジニアリングやphpソースコードの知識なしでは非常に困難です。最後の1つについては、memory_get_usageでメモリリークコードのバイナリ検索を使用できます。

最近、アプリケーションでこの問題に遭遇しました。私が収集したのは、同じような状況です。PHPのcliで実行されるスクリプトで、何度もループします。私のスクリプトはいくつかの基盤となるライブラリに依存しています。特定のライブラリが原因であると思います。適切な破壊メソッドをクラスに追加しようとしても無駄に数時間も無駄になりました。別のライブラリへの長い変換プロセスに直面しました（同じ問題が発生する可能性があります）私の場合、問題の大まかな回避策を思いつきました。

私の状況では、Linux cliで、一連のユーザーレコードをループし、それぞれについて、作成したいくつかのクラスの新しいインスタンスを作成していました。私は、PHPのexecメソッドを使用してクラスの新しいインスタンスを作成し、それらのプロセスが「新しいスレッド」で実行されるようにすることにしました。ここに私が言及しているものの本当に基本的なサンプルがあります：

foreach ($ids as $id) {
   $lines=array();
   exec("php ./path/to/my/classes.php $id", $lines);
   foreach ($lines as $line) { echo $line."\n"; } //display some output
}

明らかにこのアプローチには制限があり、ウサギの仕事を簡単に作成できるため、これの危険性に注意する必要があります。 、私の場合のように。

私は同じ問題に遭遇し、私の解決策はforeachを通常のforに置き換えることでした。詳細はわかりませんが、foreachがオブジェクトへのコピー（または何らかの方法で新しい参照）を作成するようです。通常のforループを使用して、アイテムに直接アクセスします。

phpのマニュアルを確認するかgc_enable()、ガベージを収集する関数を追加することをお勧めします...つまり、メモリリークはコードの実行方法に影響しません。

PS：phpには、gc_enable()引数を取らないガベージコレクタがあります。

最近、PHP 5.3のラムダ関数を削除すると、余分なメモリが使用されることに気付きました。

for ($i = 0; $i < 1000; $i++)
{
    //$log = new Log;
    $log = function() { return new Log; };
    //unset($log);
}

理由はわかりませんが、関数が削除された後でも、ラムダごとに250バイト余分にかかるようです。

PHPが関数の後にGCのみを実行することについて述べていることが真である場合、回避策/実験として、ループの内容を関数内にラップすることができます。

私が抱えていた1つの大きな問題は、create_functionを使用することでした。ラムダ関数と同様に、生成された一時的な名前をメモリに残します。

メモリリークのもう1つの原因（Zend Frameworkの場合）はZend_Db_Profilerです。Zend Frameworkでスクリプトを実行する場合は、無効になっていることを確認してください。たとえば、私は私のapplication.iniに次のようなものがありました：

resources.db.profiler.enabled    = true
resources.db.profiler.class      = Zend_Db_Profiler_Firebug

約25.000クエリ+その前の処理の負荷を実行すると、メモリは素晴らしい128Mb（私の最大メモリ制限）になりました。

設定するだけで：

resources.db.profiler.enabled    = false

20 Mb未満に保つのに十分でした

このスクリプトはCLIで実行されていましたが、Zend_Applicationをインスタンス化してブートストラップを実行していたため、「開発」設定を使用していました。

xDebugプロファイリングでスクリプトを実行するのに本当に役立ちました

私はそれが明示的に言及されているのを見ませんでしたが、xdebugは（2.6の時点で）時間とメモリのプロファイリングに優れています。生成した情報を取得して、選択したGUIフロントエンド（webgrind（時間のみ）、kcachegrind、qcachegrindなど）に渡すことができ、さまざまな問題の原因を見つけるのに役立つ非常に便利な呼び出しツリーとグラフを生成します。

例（qcachegrindの場合）：

この会話には少し遅れますが、Zend Frameworkに関連することを共有します。

php 5.2.9で開発されたZFアプリで動作するようにphp 5.3.8を（phpfarmを使用して）インストールした後、メモリリークの問題が発生しました。私は、仮想ホスト定義のApacheのhttpd.confファイルでメモリリークがトリガーされていることを発見しましたSetEnv APPLICATION_ENV "development"。この行をコメント化した後、メモリリークは停止しました。私のphpスクリプトでインライン回避策を考え出そうとしています（主にメインのindex.phpファイルで手動で定義することにより）。

ここでは言及されていませんが、参考になるかもしれない1つのことは、xdebugとxdebug_debug_zval（ 'variableName'）を使用して参照カウントを確認することです。

邪魔になるphp拡張機能の例、Zend ServerのZ-Rayも提供できます。データ収集が有効になっている場合、ガベージコレクションがオフになっているかのように、各反復でメモリの使用が膨らみます。