php_PHP チュートリアルでの永続ストレージ モジュールの開発の概要
- WBOYオリジナル
- 2016-07-13 17:47:231040ブラウズ
プロジェクトでは、戦闘中の一部のスキル データやアイテムなど、大規模な固定形式のデータをロードする必要があるこの要件がよくあります。これらのデータは読み取り専用データであり、現在、約数万の複雑なデータがあり、シリアル化すると、プレーン テキストは約 20M になります。 PHPファイルに配列を直接入れようとしましたが、requireファイルは非常に時間がかかり、数十ミリ秒かかる可能性があり、数十ミリのデータをロードする必要があるため、現時点ではIOが非常に重いことがわかりました。 SQLite について調べてみたところ、これは比較的信頼性が高いことが分かりました。しかし、問題は、たとえば、操作関数の書き込みが非常に使いにくいことです。自分自身の拡張です。こうして投げの旅が始まりました。
私が当初考えていたのは、MINIT で zend_execute_script メソッドを直接呼び出して php ファイルをロードし、zval を返してグローバル変数に格納することでした。その結果、よく考えてみると、それはただの妄想だったことが分かりました。その理由は、MINIT 中に php vm が初期化されていないため、zend_execute_script メソッドを呼び出すことができず、このメソッドは zval を返さないためです。zval を取得したい場合は、EG から取得する必要があります。 、非常に面倒です。
そこで、考えを変えて、unserialize/serialize を使用してみました。MINIT ステージ中に php_var_unserialize を呼び出すことができることがわかりました。それでは、まず、このメソッドを呼び出して zval を取得し、それをグローバル変数に格納し、この zval を get メソッドで返します。書いた後、テスト中にコアが呼び出されている限り実行されることがわかりました。そこでドキュメントを確認し、自分で考え、最終的に PHP_RSHUTDOWN_FUNCTION 関数が pealloc で割り当てられていない変数をすべてクリアすることを発見しました。したがって、MINIT ステージではまだ正常だったデータが、Request ステージで解放されます。
そこでドキュメントを再度確認したところ、PHP には永続的なデータ割り当てを提供する pealloc などの関数が提供されていることがわかりました。そこで、考えを変え、pealloc を使用してグローバル変数にハッシュテーブルを割り当て、ハッシュテーブルを永続的に設定しました (ありがたいことに、PHP のハッシュテーブルにはコードと vm も格納されるため、この機能があります)。しかし、問題は、php_unserialize が zval を返すだけであり、それが永続的であるかどうかを制御できないことです。 zend_hash_copy を呼び出す以外に方法はありません。書いた後、もう一度テストしてみたところ、まだコアになっていることがわかりました。昼に食事をしていて、これは浅いコピーの問題かもしれないと思いました。zend_hash_copy にはコピー機能がありますが、設定していませんでした。ディープコピー機能を追加してテストしたところ、それが機能し、非常に快適に使用できることがわかりました。 www.2cto.com
次のテストでは、20m のデータ ファイルをメモリにロードするには約 100m のメモリが必要であることが判明しました。100 個の php-cgi プロセスがある場合、さらに 10G のメモリが必要となり、これは耐え難いものです。そこで、共有メモリを使えばこの問題を解決できるのではないかと考えました。とにかく、この部分のデータが読み取れれば大丈夫です。 php-cgi のメインプロセスは MINIT 操作を担当し、子プロセスはデータのこの部分を読み取るだけで済みます。しかし、非常に厄介なのは、PHP にはユーザーがメモリを維持するためのインターフェイスが提供されていないため、一度に 1 つの機能しか実行できないことです。
PHP のハッシュテーブルの実装を詳しく調べてみたところ、非常に複雑で、realloc 関数が重要であることがわかりました。これでは言葉も出ません。現在、共有メモリのみを使用して、共有メモリから順番に領域を割り当てる単純なスレッド割り当て機能が実装されています。しかし幸いなことに、関数のこの部分はサイズ変更関数にはまったく必要ありません。なぜなら、私の目標はphp_var_unserializeで取得したzvalを共有メモリにコピーすることであり、明らかにサイズはすでにわかっているからです。また、これは新品のコピーであるため、updatea 関数は必要ありません。やっと終わってみると使えることが分かり、確かにメモリ使用量は減りました。
次に、ストレステストを実行したところ、突然コアが再び起動したことがわかりました。なぜでしょうか。コアファイルによると、内部のハッシュテーブルのrefcountが0になっていることが判明しました。そのため、さまざまなテストを通じて、シングルスレッドの状況では問題ありませんが、高圧下のマルチスレッドの状況でのみハングアップすることがわかりました。そこで、refcount が変更されるのではないかと考えました。複数のスレッドによって変更されると、めちゃくちゃになるはずです。それではどうすればいいでしょうか？ロックできません。
よく考えてみると、トップレベルの zval の refcount を、この zval を返すたびに php-cgi のプロセス数より大きい値に変更すれば、次のような場合でも問題ないのではないかとふと思いました。 0 にはまったく変化しないので、混乱します。そこで、それを修正して再度テストしてみたところ、確かに信頼できることがわかりました。
この時点で、問題全体は基本的に解決されます。ただし、Php-cgi を再起動すると、依然としてコアが発生します。その理由は、使用されている一部の変数が強制的に 0 に書き込まれているためです。実際、共有メモリの正しい使用法は、あるプロセスが書き込み、別のプロセスが読み取りを行うことですが、私のアプリケーションでは共有メモリが絶対アドレスとして使用されるため、ある場所で書き込み、別の場所で読み取ることは不可能です。 shmat 以外では 2 番目のパラメータは固定値に変更されますが、これにはプロセスのアドレス割り当てを完全に理解し、どのメモリがまったく使用できないかを把握する必要があります。ただし、これは問題ありません。Php-cgi プロセスにはメモリ制限があるため、php-cgi の実行中に使用できないメモリ部分を見つけることができるはずです。ただし、具体的な状況については次に詳細に検討する必要があります。
著者Wuxinyun