PHP における巨大なデータ オブジェクトのメモリ オーバーヘッドに関する問題の研究

PHP における巨大なデータ オブジェクトのメモリ オーバーヘッドに関する研究
まず誤解しないでいただきたいのですが、私はこの問題に関する研究結果を公開していませんが、この問題の分析と研究に協力していただきたいと思っています。 :)

問題の背景を簡略化して説明します。PHP で実装された Web サイトでは、すべてのプログラム ファイルの先頭に共通ファイル common.php が含まれます。現在、ビジネス上のニーズにより、 $huge_array = array(1,2,3,...,500000) のように、「巨大な」データ オブジェクト (約 500k の int 値を含む配列オブジェクト) が common.php で定義されています。システム全体で $huge_array への「読み取り」アクセスのみが存在します。システムは 100 の同時リクエストで安定して実行し続ける必要があると仮定します。

質問 1: $huge_array は common.php ソース ファイルで約 10M を占有し (当面は問題ありません)、メモリにロードされると 4M を占有する可能性があります (単なる推定です。サイズを正確に測定することは、この記事で議論する点ではありません)。問題は、PHP 自体が HTTP リクエストを処理するたびに独立したプロセス (またはスレッド) を開始するため、この約 4M のメモリ ブロックをメモリに再ロードする必要があるということです。メモリを共有できない場合、同時に 400M 近くの物理メモリを占有する可能性があり、メモリ使用量とメモリ アクセス効率の点で非常に不利になります。

質問 2: 特定のキャッシュ メカニズム (APC、XCache など) が有効になっている場合、そのようなキャッシュ メカニズムにはオペコードをキャッシュする機能があることがわかっていますが、スクリプトのコンパイル プロセスが短縮されるだけのようです。反復的な作業の場合、共有メモリは実行時の変数の読み込みにも役割を果たすことができますか?結局のところ、これらの多くの int 値はオペコードの一部としても存在する必要があるため、それが特定の役割を果たすことを願っています。

質問 3: 上記の XCache によるオペコードのキャッシュが目的を達成できない場合、XCache を直接操作しても効果はありますか?つまり、$huge_array は common.php に記述されるのではなく、キャッシュ エンジンに記述されます。

この記事の目的は、分析と調査を通じて、この使用法がメモリ使用量のボトルネックを引き起こすかどうか、および問題がある場合はそれを最適化する方法を判断することです。もちろん、巨大なデータ オブジェクト自体のサイズを削減するためにあらゆる手段を試すことが最初に考慮すべき最も重要なことですが、データ構造とアルゴリズムについてはこの記事では説明しません。コードを書く時間がない場合は、ソリューションが合理的である限り、この問題に関する独自の分析や見解を表明することができます。 , テストコードを書いてみたいと思います^_^
。

―――――――――――――――――――――――――――――――――
CSDN フォーラムが提供するプラグイン拡張機能をベースに、署名ファイル ツールを作成し、皆さんと共有しました。技術的な交流は歓迎です :)

共有先:
------解決策---------
データ量が500kを超えていますよね？インデックスを検討してから、セグメントごとに処理する必要があるのはなぜでしょうか。 ? ?
------解決策-----
1. はい、再保存する必要があります。メモリ読み込み中
2. すべてのプログラム ファイルにこれが含まれているため、オペコード
の一部でもあるため、キャッシュする必要があります。 3. それは非常に退屈なことです。データ構造とアルゴリズムを最適化する方が良いです
-----解決策------ - --
1. 上司が言いました
2. これはオペコードの一部なので、もちろん最適化する必要があります
3. コンパイル時間がインデックスによってデータを取得する時間よりも長い場合、なぜコンパイルする必要があるのでしょうか?キーに応じて対応するデータを取得するためだけにコンパイルするのに、キーに応じてデータを取得する方法があるのに、なぜ PHP の配列データ構造を使用する必要があるのでしょうか。この質問は、データを txt ファイルから取得すべきか、それとも含まれている PHP から取得すべきか、というようなものです。

例えば、1.txtの内容は以下の通りです
1111
2222
3333
4444
…

1.phpの内容は以下の通りです
$a = 配列(
1111、
2222、
3333、
4444、
…
);

1の場合。phpの各プロセスは$aを初期化し、$a[3]
を取得する必要があります。 1.txt の場合は、4 行目 (3 1) の内容を素早く取得する方法を最適化するだけで、すべてのプロセスで共有できます。

しかし、ここには問題があります。同時実行性の問題です。同時実行性の問題を合理的に最適化するにはどうすればよいでしょうか?

この問題を解決する一般的な方法はありません。時間のためのスペース (同時待機時間なしで 400M)、またはスペースのための時間 (4M、ただしデータ取得時に待機時間はあります) のいずれかです。


-----解決策--------------------------------
共有メモリはビッグデータを処理すると思います。これは必要です。そうしないと、ビッグデータのためにすべての http プロセスでメモリ負荷が増加します。 Xcache と apc は両方ともオペコード キャッシュですよね?つまり、PHP が毎回字句解析を使用せず、オペコードの実行段階に直接移行する場合でも、重要な点は、http If リクエストごとにメモリが 1 回割り当てられるということです。この大きな配列を memcache に保存すると、リクエストはメモリの一部を共有します。書き込み操作がないため、memcache での同時読み取りが 100 件発生しても問題はありません。楽観的ロックをサポートします。
------解決策---------
まず、これを memcache に入れます

必要な場所で取り出すだけです、それだけです、それで十分です
-----解決策---------

Quote:

定数データとして多数の int 値を含む配列の初期値は、オペコードの一部である必要があります。それはまだわかりませんが、プログラム内の変数に値を割り当てるために使用する場合、最初にそれをロードするためにメモリが割り当てられます。割り当てられていない場合、この変数はオペコードが格納されているアドレスを直接指していることになります。そうすると、オペコードが格納されているブロック メモリはプロセス間で共有されているのかという疑問が再び生じます。

これについては考えないでください。オペコードは文法コンパイルのステップを省略しているだけです。たとえば、
$a = 1 1;
opcodeに置き換えると
となります。 ZEND_ADD ~0 1 1
~0 が $a を置き換えるだけです。実際に実行する場合、~0 は別途スペースを割り当てる必要があります。それ以外の場合、PHP はどのようにしてデータを取得するのでしょうか。別のプロセスがこの値を変更した場合、別のプロセスに影響しますか?各プロセスの論理的な正しさを保証することはできないのでしょうか?各プロセスには同じコードがあるため、$a がまだ新しく初期化された状態にあるかどうかはわかりません。

したがって、オペコードのキャッシュはデータをキャッシュせず、別のコード (スクリプト) 形式をキャッシュするだけです。特定のデータは実行時にメモリ内で再割り当てする必要があります。

オペコードの詳細については、私をクリックしてください

さらに、私が述べた例 (もちろん 1.txt は、memcache や SQL などの任意のツールで置き換えることができます) が必要な場合は、割り当てられたメモリ領域を読み取るなどのインターフェイスを開発できるだけです。次のコンテンツを保存するためにこのメモリ領域を使用することもできます。次のコンテンツを削除して、各プロセスのメモリ領域を確実に削減します

疑似コードの例:


while($data = get()) {
// 同じことをします
}


に来てください foreach($datas as $data){
}

データの取得時間を長くしてメモリ消費量を削減

------解決策------------------
このトピックに参加したいのですが、個人的な意見です。レベルが限られているので、キャッシュについてはよくわからないので、何とも言えません


別の角度から私の個人的な意見を述べさせてください—

Web プログラミングでは、単に問題を解決するだけではなく、サーバー接続を含む同時実行性を考慮する必要があります
これは、デスクトップ開発に携わる多くの人が理解していないことであり、「php はひどい」などの言葉につながっています

php の利点は、簡単な問題をすばやく解決し、完了してクライアントにスローし、接続を終了して次のリクエストのために解放できることです
複雑な計算は実際には、より多くのコア言語と高品質のサーバーを使用して完了する必要があります

主な目的は結果を計算することであるため、複雑な計算によって消費されるリソースはコア言語と高性能サーバーにとって価値があります
たとえば、NASA のサーバーと上記の実用的なプログラムは、卓越性を追求する必要があり、小数点以下の桁数の計算を誤ると、「火星が地球に衝突する」という結果が生じる可能性があります
。
しかし、情報拡散ネットワークへの損失は甚大です。1 秒が消費されるごとに、あなたの情報が 1 人、あるいは数十人に伝達されなくなる可能性があるからです
メモリ消費量と消費時間は同じですが、メモリ使用量が多すぎると、TCP 接続が不安定になります
。

したがって、パラメータを大きくするとプログラムの柔軟性が向上し、より多くのユーザーに適応できる可能性がありますが、一般的なネットワーク アクセスにとっては失敗した選択です
これらのパラメータを分割し、ユーザーグループを分類する必要があります。目的を達成するには、各ユーザーが選択するパラメータを少なくするだけで十分です
。 たとえば、グローバル Web サイトの場合、パラメーター プログラムの適応のためにすべての言語をまとめる代わりに、ユーザーは言語を選択し、この言語のコードのみを記述します

複雑な計算がある場合は、他の言語またはコントロールを使用して、特定の所定のプロセスを完了し、Web プログラムの応答プロセスを削減する必要があります
#6 は、ある状況について話しています。もちろん、これはあなたのニーズに合わないかもしれませんが、彼の定式化は Web サイトのビジネス ロジックと一致しています
。

ここまで言っても、あなたのニーズを解決できていないかもしれません。読んでいただけて光栄です...
-----解決策---------- --- -------
4M、カカ、大きすぎません

それを値に単純化し、現在実行中の PHP のピーク メモリを測定して比較します。


-----解決策---------
このコードが何をするかを見てくださいファイルをメモリにロードする必要はありません

<?php<br />
/*<br />
111<br />
222<br />
333<br />
444<br />
555<br />
<br />
*/<br />
<br />
<br />
$file = new SplFileObject(__FILE__);<br />
$file->seek(3);//这里是行数，从0开始<br />
echo $file->current().'<br>';<br />
?>

約 50M の XML のテストにかかる時間は 0.01 秒未満です。行数が増えるほど、より多くの時間がかかります