PHP ガベージコレクションメカニズム - パフォーマンスに関する考慮事項-PHPチュートリアル-php.cn

PHP ガベージコレクションメカニズム - パフォーマンスに関する考慮事項

伊谢尔伦

リリース： 2016-11-22 09:57:49

オリジナル

1120 人が閲覧しました

リサイクルはパフォーマンスにわずかな影響を与える可能性がありますが、これは PHP 5.2 と PHP 5.3 を比較した場合にのみ発生します。 PHP 5.2 ではログをまったく記録しない場合よりも遅くなる可能性がありますが、PHP 5.3 では PHP ランタイムに加えられたその他の変更により、このパフォーマンスの低下が軽減されます。

パフォーマンスに影響を与える主な領域は 2 つあります。 1 つはメモリ領域の節約であり、もう 1 つはガベージコレクションメカニズムがメモリクリーニングを実行する際の実行時間 (実行時遅延) の増加です。両方の領域を見ていきます。

メモリフットプリントの節約

まず第一に、ガベージコレクションメカニズムを実装する全体の理由は、前提条件が満たされた後に循環参照される変数をクリーンアップすることでメモリフットプリントを節約することです。 PHP の実行では、ルートバッファがいっぱいになるか、gc_collect_cycles() 関数が呼び出されると、ガベージコレクションが実行されます。以下の図は、PHP 5.2 および PHP 5.3 環境における次のスクリプトのメモリ使用量を示しています。ただし、スクリプトの開始時に PHP 自体が占有する基本メモリは除きます。

例 #1 メモリ使用例

<?php
    class Foo
    {
        public $var = &#39;3.1415962654&#39;;
    }
    $baseMemory = memory_get_usage();
    for ( $i = 0; $i <= 100000; $i++ )
    {
        $a = new Foo;
        $a->self = $a;
        if ( $i % 500 === 0 )
        {
            echo sprintf( &#39;%8d: &#39;, $i ), memory_get_usage() - $baseMemory, "\n";
        }
    }
?>

ログイン後にコピー

PHP ガベージコレクションメカニズム - パフォーマンスに関する考慮事項

この非常に理論的な例では、オブジェクトを作成し、このオブジェクトのプロパティがオブジェクト自体を指すように設定されます。一般的なメモリリークは、ループの次の反復中にスクリプト内の変数が再度コピーされるときに発生します。この例では、2 つの変数コンテナー (オブジェクトコンテナーと属性コンテナー) がリークされていますが、ルート候補は 1 つだけ見つかります: 設定解除された変数です。 10,000 回繰り返した後 (結果としてルートの可能性は合計 10,000 個になります)、ルートバッファーがいっぱいになると、ガベージコレクションメカニズムが実行され、ルートの可能性があるメモリが解放されます。これは、PHP 5.3 のノコギリ状のメモリ使用量グラフで簡単にわかります。 10,000 回の繰り返しが実行されるたびに、ガベージコレクションが実行され、関連する再利用された参照変数が解放されます。この例では、リークされたデータ構造が非常に単純であるため、ガベージコレクションメカニズム自体はそれほど多くの作業を行う必要はありません。このグラフから、PHP 5.3 の最大メモリフットプリントは約 9 Mb であるのに対し、PHP 5.2 のメモリフットプリントは増加し続けていることがわかります。

実行時の速度低下

ガベージコレクションがパフォーマンスに影響を与える 2 番目の領域は、リークしたメモリを解放するのにかかる時間です。これにどれくらいの時間がかかるかを確認するために、上記のスクリプトを少し変更して、繰り返しを増やし、ループ内のメモリ使用量の計算を削除しました。

例 #2 GC パフォーマンスへの影響

<?php
    class Foo
    {
        public $var = &#39;3.1415962654&#39;;
    }
    for ( $i = 0; $i <= 1000000; $i++ )
    {
        $a = new Foo;
        $a->self = $a;
    }
    echo memory_get_peak_usage(), "\n";
?>

ログイン後にコピー

これを実行します。スクリプトは 2 回実行されます。1 回目は zend.enable_gc を構成してガベージコレクションがオンになったとき、もう 1 回はオフになったときです。

例 #3 上記のスクリプトの実行

time php -dzend.enable_gc=0 -dmemory_limit=-1 -n example2.php
# and
time php -dzend.enable_gc=1 -dmemory_limit=-1 -n example2.php

ログイン後にコピー

私のマシンでは、最初のコマンドは約 10.7 秒かかり、2 番目のコマンドは 11.4 秒かかりました。時間が7%増加しました。ただし、このスクリプトを実行するときのピークメモリ使用量は、931Mb から 10Mb に 98% 削減されました。このベンチマークはあまり科学的ではなく、実際のアプリケーションデータを代表するものでもありませんが、メモリフットプリントの観点からガベージコレクションの利点を示しています。良いニュースとしては、このスクリプトでは、実行中に循環参照変数がより多く出現すると、メモリの節約がさらに大きくなり、毎回の時間の増加率が 7% になるということです。

PHP 内部 GC 統計

PHP 内部で、ガベージコレクションメカニズムがどのように動作するかに関する詳細情報を表示できます。ただし、この情報を表示するには、まず PHP を再コンパイルして、ベンチマークとデータ収集コードを使用できるようにする必要があります。必要に応じて ./configure を実行する前に、環境変数 CFLAGS を -DGC_BENCH=1 に設定する必要があります。次のコマンド文字列はまさにそれを行います:

例 #4 GC ベンチマークを有効にするために PHP を再コンパイルする

export CFLAGS=-DGC_BENCH=1
./config.nice
make clean
make

ログイン後にコピー

新しくコンパイルされた PHP バイナリファイルを使用して上記のサンプルコードを再実行すると、PHP の実行が終了した後、次の内容が表示されます。情報:

例 #5 GC 統計

GC Statistics
-------------
Runs:               110
Collected:          2072204
Root buffer length: 0
Root buffer peak:   10000
      Possible            Remove from  Marked
        Root    Buffered     buffer     grey
      --------  --------  -----------  ------
ZVAL   7175487   1491291    1241690   3611871
ZOBJ  28506264   1527980     677581   1025731

ログイン後にコピー

主な情報統計は最初のブロックにあります。ガベージコレクションメカニズムが 110 回実行され、この 110 回の実行で合計 200 万を超えるメモリ割り当てが解放されたことがわかります。ガベージコレクションメカニズムが少なくとも 1 回実行される限り、ルートバッファーピーク (ルートバッファーピーク) は常に 10000 です。

結論

通常、PHP のガベージコレクションメカニズムは、ループコレクションアルゴリズムが実際に実行されているときにのみ時間を消費します。増加。ただし、通常の (小規模な) スクリプトでは、パフォーマンスへの影響はまったくありません。

ただし、リサイクルメカニズムが実行されている通常のスクリプトの場合、メモリの節約により、より多くのそのようなスクリプトをサーバー上で同時に実行できるようになります。使用メモリの合計が上限に達していないためです。

この利点は、長時間実行されるテストスイートやデーモンスクリプトなど、長時間実行されるスクリプトで特に顕著です。同時に、一般的に Web スクリプトよりも実行時間が長い PHP-GTK アプリケーションの場合、新しいガベージコレクションメカニズムによって、メモリリークの解決が難しいという長年の見方が大きく変わるはずです。