InstagramでPythonガベージコレクターを切断し、ライブを開始することについて

未使用のデータを追跡して削除することでメモリを解放するPythonガベージコレクター（GC）を無効にすることで、Instagramは10％高速になりました。 はい、あなたは正しいと聞きました！ ガベージコレクタを無効にすることにより、消費されるメモリ量を削減し、プロセッサキャッシュの効率を向上させることができます。 なぜこれが起こっているのか知りたいですか？ その後、シートベルトを締めてください！

Webサーバーの実行方法

Instagram Webサーバーは、Djangoでマルチプロセスモードで実行されます。このプロセスでは、マスタープロセスが自分自身をコピーし、ユーザーからのリクエストを受信する多数のワークフローを作成します。 アプリケーションサーバーとして、プリフォークモードでuWSGIを使用して、マスタープロセスとワークフロー間のメモリの分散を制御します。

Djangoのメモリ不足を防ぐために、uWSGIマスタープロセスは、その常駐メモリ（RSS）が所定の制限を超えたときにワークフローを再起動する機能を提供します。

メモリの仕組み

まず、マスターが生成した直後にRSSワークフローが急速に成長し始める理由を見つけることにしました。 RSSは250 MBから始まりますが、使用される共有メモリのサイズは数秒で250 MBからほぼ140 MBに減少することに気付きました（共有メモリのサイズは/proc/PID/smaps ）。 ここの数字は絶えず変化しているため、あまり興味深いものではありませんが、割り当てられたメモリがどれだけ速く解放されるか（合計メモリのほぼ3分の1）が重要です。 次に、この共有メモリが各プロセスの開始時にプライベートメモリになる理由を調べることにしました。

私たちの仮定：コピーオンリード

Linuxカーネルには、子プロセスの作業を最適化するコピーオンライト （CoW）メカニズムがあります。 子プロセスは、その存在の開始時に、メモリの各ページをその親と共有します。 ページは、記録中にのみプロセスのメモリにコピーされます。

しかし、Pythonの世界では、参照カウントのために興味深いことが起こります。 Pythonオブジェクトを読み取るたびに、インタープリターはその参照カウンターを増やします。これは本質的に、内部データ構造への書き込み操作です。 これによりCoWが発生します。 Pythonでは、実際にコピーオンリード（CoR）を使用していることがわかりました！

 #define PyObject_HEAD \ _PyObject_HEAD_EXTRA \ Py_ssize_t ob_refcnt; \ struct _typeobject *ob_type; ... typedef struct _object { PyObject_HEAD } PyObject; 

問題は熟成です：コードオブジェクトなどの不変オブジェクトの書き込み時にコピーしますか？ PyCodeObjectは実際にはPyObject 「サブクラス」 PyCodeObject 、明らかにそうです。 最初のアイデアは、PyCodeObjectのリンクカウントを無効にすることでした。

試行番号1：コードオブジェクトのリンクカウントを無効にする

Instagramの簡単なものから始めます。 実験として、CPythonインタープリターに小さなハックを追加し、コードオブジェクトの参照カウンターが変更されないようにしてから、このCPythonを実稼働サーバーの1つにインストールしました。

結果は私たちを失望させました：共有メモリの使用において何も変わっていません。 これがなぜ起こるのかを探ろうとすると、ハックが機能したことを証明する信頼できるメトリックが見つからず、共有メモリとコードオブジェクトのコピーの間の接続も証明できないことに気付きました。 明らかに、私たちは何かを見失った。 結論：あなたの理論に従う前に、それを証明してください。

ページ割り込み分析

Copy-on-Writeのトピックについて少し調べてみると、Copy-on-Writeはメモリにページがない場合のエラー（ページフォールトまたはページの中断）に関連していることがわかりました。 各CoW操作により、プロセスで改ページが発生します。 Linuxに組み込まれているパフォーマンス監視ツールを使用すると、ページ割り込みなどのシステムイベントを記録でき、可能であればスタックトレースをポップアップ表示することもできます。

再び運用サーバーにアクセスして再起動し、マスタープロセスが子プロセスを生成し、ワークフローのPIDを認識してから次のコマンドを実行するまで待機しました。

 perf record -e page-faults -g -p <PID> 

スタックトレースを使用して、プロセスでページの中断がいつ発生するかを把握しました。



結果は予想とは異なります。 主な容疑者はコードオブジェクトをコピーすることではなく、 gcmodule.cが所有し、ガベージコレクターの起動時に呼び出されるcollectメソッドです。 CPythonでのGCの仕組みを読んだ後、次の理論を開発しました。

CPythonのガベージコレクターは、しきい値に基づいて決定論的に呼び出されます。 デフォルトのしきい値は非常に低いため、ガベージコレクタは非常に早い段階で開始されます。 オブジェクトの作成に関する情報を含むリンクリストを提供し、リンクリストはガベージコレクション中に混合されます。 リンクされたリストの構造はオブジェクト自体と一緒に存在するため（ ob_refcountと同様）、リンクされたリスト内でこれらのオブジェクトをシャッフルすると、対応するページのCoWが発生します。これは不幸な副作用です。

 /* GC information is stored BEFORE the object structure. */ typedef union _gc_head { struct { union _gc_head *gc_next; union _gc_head *gc_prev; Py_ssize_t gc_refs; } gc; long double dummy; /* force worst-case alignment */ } PyGC_Head; 

試行番号2：ガベージコレクターを無効にしてみてください

ガベージコレクターが裏切り者に裏切ったので、オフにします。

ダウンロードスクリプトにgc.disable()呼び出しを追加しました。 サーバーを再起動しました-そして再び失敗しました！ 再度perfを見ると、 gc.collectがまだ呼び出されており、メモリへのコピーがまだ進行中であることがわかります。 GDBでのデバッグ後、使用する外部ライブラリの1つ（msgpack）がgc.enable()を呼び出してガベージコレクターを復活させるため、ブートスクリプトのgc.disable()は役に立たないことがgc.disable()ました。

msgpackにパッチを適用することは、他のライブラリが私たちに通知せずに同じことをする可能性を開いたため、受け入れられませんでした。 まず、ガベージコレクターを無効にすることが本当に役立つことを証明する必要があります。 答えは再びgcmodule.cます。 gc.disableの代替として、 gc.set_threshold(0)を実行しgc.disable今回は単一のライブラリーがこの値をその場所に返しませんでした。

したがって、各ワークフローの共有メモリの量を140 MBから225 MBに増やすことに成功し、ホスト上の使用メモリの合計量が各マシンで8 GBに減少しました。 これにより、すべてのDjangoサーバーでRAMの25％が節約されました。 このような空き領域の予約により、より多くのプロセスを開始し、常駐メモリのしきい値を上げることができます。 その結果、Djangoレイヤーのスループットが10％以上向上します。

試行番号3：ガベージコレクターを完全に無効にする

多くの設定を試した後、私たちは理論をより広いコンテキストで、つまりクラスターでテストすることにしました。 ガジェットコレクターをオフにするとWebサーバーのリブートがさらに遅くなり、結果はすぐに現れ、継続的な展開プロセスが崩れました。 通常、再起動には10秒もかかりませんでしたが、ガベージコレクターをオフにすると、最大で60秒かかりました。

 2016-05-02_21:46:05.57499 WSGI app 0 (mountpoint='') ready in 115 seconds on interpreter 0x92f480 pid: 4024654 (default app) 

動作が決定論的ではなかったため、このバグを再現することは困難でした。 多くの実験の後、再現の正確なステップを決定することができました。 これが発生すると、このホストの空きメモリがほぼゼロに低下し、キャッシュ全体が一杯になりました。 その後、すべてのコードまたはデータをディスクから読み取る必要があり（DSK 100％）、すべてがゆっくりと動作しました。

これは、インタープリターが停止したときにPythonが最終的なガベージコレクションを実行していることを示している可能性があります。これにより、非常に短い時間で使用されるメモリ量が大きく跳ね上がる可能性があります。 そして再び、私は最初にそれを証明し、次にそれを修正する方法を決めることにしました。 そのため、Python用のuWSGIプラグインでPy_Finalize呼び出しをコメントアウトすると、問題はなくなりました。

明らかに、 Py_FinalizeオフにすることはできませんPy_Finalize 。 多くの重要なクリーニング手順は、この方法に依存していました。 最後に、ガベージコレクションを完全にオフにする動的フラグをCPythonに追加しました。

最後に、ソリューションを大規模に適用する必要がありました。 すべてのサーバーに適用しようとしましたが、これもまた継続的な展開プロセスを中断しました。 ただし、今回は古いプロセッサモデル（Sandy Bridge）を搭載したマシンのみが影響を受け、再現するのはさらに困難でした。 結論：古い顧客/機器は最も簡単に破損するため、常にテストしてください。

継続的な展開プロセスは何が起こっているかを理解するのに十分な速さなので、インストールスクリプトに別atopユーティリティを追加しました。 これで、キャッシュがほぼ一杯になり、すべてのuWSGIプロセスが多くのMINFLT（メモリ内の欠落ページのマイナーエラー）をスローした瞬間をキャッチできました。


また、パフォーマンスプロファイリングを実行すると、 Py_Finalizeに遭遇しPy_Finalize 。 シャットダウン時に、ガベージコレクションに加えて、Pythonはいくつかのクリーンアップ操作を実行します。タイプオブジェクトの破棄やモジュールのアンロードなどです。 そして、それは再び一般的な記憶を傷つけました。

試行番号4：ガベージコレクターをシャットダウンする最後の手順：クリーニングなし

しかし、なぜ何かをわざわざ掃除するのですか？ プロセスは終了し、代わりのプロセスを受け取ります。 心配する必要があるのは、アプリケーションの背後でクリーンアップするatexit関数ハンドラです。 ただし、Pythonのクリーンアップについては心配しないでください。 最終的にブートスクリプトを変更した方法は次のとおりです。

 # gc.disable() doesn't work, because some random 3rd-party library will # enable it back implicitly. gc.set_threshold(0) # Suicide immediately after other atexit functions finishes. # CPython will do a bunch of cleanups in Py_Finalize which # will again cause Copy-on-Write, including a final GC atexit.register(os._exit, 0) 

ソリューションは、atexit関数がレジスタから逆の順序で実行されるという事実に基づいています。 atexit関数は残りのクリーンアップを完了し、 os._exit(0)を呼び出して現在のプロセスを完了します。

2行のみを変更したため、最終的にすべてのサーバーにソリューションを展開しました。 メモリのしきい値を慎重に調整することで、合計パフォーマンスが10％向上しました！

振り返る

パフォーマンスの改善について考えるとき、いくつか質問がありました。

最初に、ガベージコレクションなしではPythonメモリがオーバーフローしないようにすべきです。 （すべてのオブジェクトがヒープに格納されているため、Pythonのメモリには実際のスタックがないことを思い出してください）

幸いなことに、これはそうではありません。 Pythonでオブジェクトを解放する主なメカニズムは、参照カウントです。 オブジェクトへの参照が削除されると（ Py_DECREF呼び出されると）、Pythonは常にこのオブジェクトの参照カウントがゼロに達したかどうかを確認します。 この場合、このオブジェクトのデアロケーターが呼び出されます。 ガベージコレクションの主なタスクは、リンクカウントメカニズムが機能しない場合に周期的な依存関係を破棄することです。

 #define Py_DECREF(op) \ do { \ if (_Py_DEC_REFTOTAL _Py_REF_DEBUG_COMMA \ --((PyObject*)(op))->ob_refcnt != 0) \ _Py_CHECK_REFCNT(op) \ else \ _Py_Dealloc((PyObject *)(op)); \ } while (0) 

賞品がどこから来たのかを把握しましょう

2番目の質問：パフォーマンスの向上はどこから来ますか？

ガベージコレクターをオフにすると、2つの勝利が得られます。

• 各サーバーでほぼ8 GBのRAMを解放し、それらを使用して、メモリ帯域幅が制限されているサーバーでより多くのワークプロセスを作成したり、CPU電力制限のあるサーバーでプロセスの再起動回数を減らしたりできました。
• CPUスループットも、クロックサイクル（IPC）ごとに実行される命令の数がほぼ10％増加するにつれて増加しました。

 # perf stat -a -e cache-misses,cache-references -- sleep 10 Performance counter stats for 'system wide': 268,195,790 cache-misses # 12.240 % of all cache refs [100.00%] 2,191,115,722 cache-references 10.019172636 seconds time elapsed 

ガベージコレクターを無効にすると、キャッシュミス率が2〜3％低下します。これがIPCが10％向上した主な理由です。 キャッシュミスは、プロセッサコンピューティングパイプラインの速度を低下させるため、コストがかかります。 CPUキャッシュヒット率をわずかに上げると、IPCが大幅に向上します。 実行されるコピーオンライト（CoW）操作が少ないほど、（異なるワークプロセスで）異なる仮想アドレスを持つキャッシュラインが物理メモリの同じアドレスを指すようになり、キャッシュヒット率が向上します。

ご覧のとおり、すべてのコンポーネントが想定どおりに機能するとは限らず、結果が予期しないものになる場合があります。 したがって、研究を続けて、すべてが実際にどのように機能するかに驚くことです！

ああ、仕事に来てくれませんか？ :)

wunderfund.ioは、 高頻度アルゴリズム取引を扱う若い財団です。 高頻度取引は、世界中の最高のプログラマーと数学者による継続的な競争です。 私たちに参加することで、あなたはこの魅力的な戦いの一部になります。

熱心な研究者やプログラマー向けに、興味深く複雑なデータ分析と低遅延の開発タスクを提供しています。 柔軟なスケジュールと官僚主義がないため、意思決定が迅速に行われ、実施されます。

チームに参加： wunderfund.io