php - memory_get_usage() と pmap について

Question

一部のphpプロセスのメモリ使用量を理解しようとしています。と の両方get_memory_usage()を使用してみましpmapたが、結果は約 1 桁ずれているようです。と、memory_get_usage()およびの両方を試しましたが、(3 種類すべての中で最大のもの) を使用しても、pmap を介して報告される内容にはまだ膨大なものがあります。memory_get_usage(true)memory_get_peak_usage(true)memory_get_peak_usage(true)

より具体的にはmemory_get_peak_usage(true)、php スクリプト内で毎分呼び出すと、1.75MB から 3.5MB の範囲の値が返されますが、 の典型的な結果は次のpmap -d PIDようになります。

...

b7839000       4 r---- 0000000000008000 0ca:00060 libcrypt-2.11.1.so
b783a000       4 rw--- 0000000000009000 0ca:00060 libcrypt-2.11.1.so
b783b000     156 rw--- 0000000000000000 000:00000   [ anon ]
b7864000       8 rw--- 0000000000000000 000:00000   [ anon ]
b7867000      12 r-x-- 0000000000000000 0ca:00060 libgpg-error.so.0.4.0
b786a000       4 r---- 0000000000002000 0ca:00060 libgpg-error.so.0.4.0
b786b000       4 rw--- 0000000000003000 0ca:00060 libgpg-error.so.0.4.0
b786c000       4 r---- 0000000000000000 000:00000   [ anon ]
b786d000      16 rw--- 0000000000000000 000:00000   [ anon ]
b7871000     108 r-x-- 0000000000000000 0ca:00060 ld-2.11.1.so
b788c000       4 r---- 000000000001a000 0ca:00060 ld-2.11.1.so
b788d000       4 rw--- 000000000001b000 0ca:00060 ld-2.11.1.so
bffc7000     136 rw--- 0000000000000000 000:00000   [ stack ]
f57fe000       4 r-x-- 0000000000000000 000:00000   [ anon ]
mapped: 32740K    writeable/private: 13116K    shared: 28K

私が正しく理解していれば、プロセスによって排他的に使用されるメモリであるため、書き込み可能/プライベート図が最も関連性の高い図です。13MB 近くは、によって報告された量とはかけ離れていmemory_get_peak_usage(true)ます。誰かが矛盾を説明できますか？

Answer 1

私の理解ではmemory_get_peak_usage()、スクリプトによって使用されているメモリの量が返されます。したがって、PHP のオーバーヘッドは含まれていません。

PHP スクリプトに割り当てられたメモリのピークをバイト単位で返します。

より少ない拡張機能でコンパイルすることにより、PHP が使用するメモリを減らすことができます。

PHP 自体は大規模なアプリケーションであり、特にデフォルトの拡張機能が含まれています。私たち (php 開発者として) は、次のような単純なコードを記述しsimplexml_load_string()て、魔法が起こるのを見ることができますが、その魔法を動かすコードは、メモリのどこかで動き回っています。の出力を見ると、phpinfo()インストールされている拡張機能の数がわかります。PHP の内部には、PHP を受け取ってそれを OPCODE に変換するコードと、それらの Opcode を実行するコードがあります。PHP の各インスタンスを実行すると、そのオーバーヘッドが発生します。

このメモリ使用量は明らかに些細なものではありませんが、当然のことです。着信 GET/POST/FILES を処理するためにすべてのコードを作成する必要がある場合、XML、ファイル、およびストリーム マジックなどを管理します。メモリ使用量はすぐに増加します。

その結果、一般的なパフォーマンス手法は、不要な拡張子をすべて削除して実行可能ファイルのサイズを縮小することです。メモリに制約のあるサーバー (ロードされているもののほとんど) の場合、いくつかの拡張機能を削除し、メモリ使用量を 9 MB から 7 MB に減らすと、より多くの apache ワーカーが実行されます。

各実行は実際には PHP 実行の個別のコピーであるため、このオーバーヘッドは共有されません。スレッド セーフ ビルドを使用した代替手段はありますが、すべての PHP 拡張機能がスレッド セーフであるとは限りません。

拡張機能 の削除 使用している機能を見てみましょう。mysqli_*? xml_*? など。また、PHP がどのように構築されているかを見てください。ここに私の構成行があります。

Configure Command => './configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-mysql=mysqlnd' '--with-gd' '--enable-soap' '--with-libxml-dir=/usr/lib/' '--with-mysql-sock=/tmp' '--with-tidy' '--with-jpeg-dir=/usr/lib/' '--with-xsl' '--with-curl' '--with-zlib' '--enable-gd-native-ttf' '--with-openssl' '--with-mcrypt' '--with-pdo-mysql=mysqlnd' '--with-mysqli=mysqlnd' '--with-bz2' '--enable-bcmath'

メモリを削っている場合は、./configure --disable-all(デフォルトの拡張機能を削除するために) PHP を構築することから始め、次に使用していた新しい拡張機能のみを明示的に追加します。私はlibxml自分のコードにもう使用していないsoapので、それらのビットを削除することもできません。tidy仕事はギアマンワーカーやコマンドラインに外注できるので、そちらも引っ張っていきます。次に、コードを実行して (ここでは単体テストを実行すると素晴らしいでしょう)、何が壊れているかを確認します。必要な拡張機能を使用して PHP を再構築し、すすぎ、繰り返します。明らかに本番環境ではこれを行わないでください。さもないと、最悪の事態が発生します。

Answer 2

バイト対ビットは 10 倍です。したがって、1.3 MBytes = 13MBits