Phusionには 、RubyにシンプルなマルチスレッドHTTPプロキシがあります（DEBおよびRPMパッケージを配布します）。 私はそれで1.3 GBのメモリ消費を見ました。 しかし、これはステートレスなプロセスには夢中です...


質問：それは何ですか？ 回答：Rubyは時間の経過とともにメモリを使用します！

この問題は私だけではありません。 Rubyアプリケーションは多くのメモリを使用できます。 しかし、なぜですか？ HerokuとNate Burkopekによると、 肥大化は主にメモリの断片化と過剰なヒープ分散によるものです。

Berkopekは、2つの解決策があると結論付けました。

1. glibcとはまったく異なるメモリアロケーター（通常はjemalloc ）を使用するか、次のいずれかを実行します。
2. マジック環境変数MALLOC_ARENA_MAX=2設定します。

問題の説明と提案された解決策が心配です。 ここで何かが間違っています...問題が完全に正しく記述されているか、またはこれらが利用可能な唯一のソリューションであるかどうかはわかりません。 また、多くの人がjemallocを魔法の銀のプールと呼んでいることを悩ませています。

魔法は私たちがまだ理解していない科学です 。 それで、私はすべての真実を見つけるために調査旅行に行きました。 この記事では、次のトピックについて説明します。

1. メモリ割り当ての仕組み。
   
2. 誰もが話しているこのメモリの「断片化」と「過剰な分散」とは何ですか？
   
3. 大きなメモリ消費の原因は何ですか？ 状況は人々が言っ​​ていることと一致していますか、それとも何か他のものがありますか？ （ネタバレ：はい、他にもあります）。
   
4. 代替ソリューションはありますか？ （ネタバレ：見つけた）。

注：この記事はLinuxにのみ関連し、マルチスレッドRubyアプリケーションにのみ関連します。

内容

• Rubyのメモリ割り当て：はじめに
  
  • ルビー
  • システムメモリアロケーター
  • コア
  • メモリ使用量の定義
• フラグメンテーションとは何ですか？
  
  • Rubyレベルの断片化
  • メモリ割り当ての断片化
• Rubyヒープページの断片化がメモリの膨張を引き起こしていますか？
• メモリ割り当てフラグメンテーションの研究
  
  • 過剰なメモリ割り当てとglibc
  • システムヒープの視覚化
• マジックトリック：割礼
• おわりに
  
  • ビジュアライザーのソースコード
  • パフォーマンスはどうですか？
  • さらにテストが必要

Rubyのメモリ割り当て：はじめに

Rubyは、上から下の3つのレベルでメモリを割り当てます。

1. Rubyオブジェクトを管理するRubyインタープリター。
   
2. オペレーティングシステムのメモリアロケータライブラリ。
   
3. コア。

各レベルを見ていきましょう。

ルビー

一方、Rubyは、 Rubyヒープページと呼ばれるメモリ領域にオブジェクトを整理します。 このようなヒープページは同じサイズのスロットに分割され、1つのオブジェクトが1つのスロットを占有します。 文字列、ハッシュテーブル、配列、クラス、または他の何かであるかどうか、それは1つのスロットを占有します。



ヒープページのスロットはビジーまたは空きです。 Rubyが新しいオブジェクトを選択すると、すぐに空きスロットを占有しようとします。 空きスロットがない場合、新しいヒープページが強調表示されます。

スロットは小さく、約40バイトです。 明らかに、たとえば1 MB行など、一部のオブジェクトはそれに適合しません。 次に、Rubyは情報をヒープページ以外の場所に保存し、この外部メモリ領域へのポインターをスロットに配置します。


スロットに収まらないデータは、ヒープページの外部に格納されます。 Rubyは、この外部データへのポインターをスロットに配置します

Rubyヒープページと外部メモリ領域の両方が、システムメモリアロケータを使用して割り当てられます。

システムメモリアロケーター

オペレーティングシステムのメモリアロケータは、glibc（Cランタイム）の一部です。 Rubyだけでなく、ほぼすべてのアプリケーションで使用されます。 シンプルなAPIがあります。

• メモリはmalloc(size)呼び出すことにより割り当てられます。 割り当てるバイト数を指定すると、割り当てアドレスまたはエラーが返されます。
• 割り当てられたメモリは、 free(address)呼び出すことによって解放されfree(address) 。

同じサイズのスロットが割り当てられるRubyとは異なり、メモリアロケーターは、任意のサイズのメモリを割り当てる要求を処理します。 後で学ぶように、この事実はいくつかの合併症につながります。

次に、メモリアロケータはカーネルAPIにアクセスします。 カーネルコールは高価であり、カーネルAPIには4 KBの倍数でしかメモリを割り当てることができないため、カーネルからのメモリチャンクがそれ自体のサブスクライバ要求よりもはるかに大きくなります。


メモリアロケータは、システムヒープと呼ばれる大きなチャンクを割り当て、その内容を共有してアプリケーションからの要求を満たします

メモリアロケータがカーネルから割り当てるメモリ領域は、ヒープと呼ばれます。 Rubyヒープのページとは関係がないため、明確にするためにシステムヒープという用語を使用します 。

メモリアロケーターは、空き領域ができるまで、システムヒープの一部を呼び出し元に割り当てます。 この場合、メモリアロケーターはカーネルから新しいシステムヒープを割り当てます。 これは、RubyがRubyヒープのページからオブジェクトを抽出する方法に似ています。


Rubyはメモリアロケータからメモリを割り当て、メモリアロケータはカーネルからメモリを割り当てます

コア

カーネルは4 KB単位でのみメモリを割り当てることができます。 そのような4Kブロックの1つはページと呼ばれます。 Rubyヒープページとの混乱を避けるために、明確にするために、 システムページ （OSページ）という用語を使用します。

理由を説明するのは困難ですが、これが最新のカーネルの動作方法です。

カーネルを介したメモリの割り当ては、パフォーマンスに大きな影響を与えます。そのため、メモリアロケータはカーネル呼び出しの数を最小限にしようとします。

メモリ使用量の定義

したがって、メモリは複数のレベルで割り当てられ、各レベルは実際に必要な量より多くのメモリを割り当てます。 Rubyヒープページには、システムヒープだけでなく、空きスロットを含めることができます。 したがって、「どのくらいのメモリが使用されていますか？」という質問に対する答えは、尋ねるレベルに完全に依存します！

topやpsなどのツールは、 カーネルの観点からメモリ使用量を表示します。 つまり、カーネルの観点からメモリを解放するには、上位レベルが協調して動作する必要があります。 後で学ぶように、これは思ったより難しいです。

フラグメンテーションとは何ですか？

メモリの断片化とは、メモリの割り当てがランダムに分散されることを意味します。 これは興味深い問題を引き起こす可能性があります。

Rubyレベルの断片化

Rubyのガベージコレクションを検討してください。 オブジェクトのガベージコレクションは、Rubyヒープページスロットを空きとしてマークし、再利用できるようにすることを意味します。 Rubyヒープのページ全体が空きスロットのみで構成されている場合、そのページ全体を解放してメモリアロケータに戻すことができます（場合によっては、カーネルに戻すこともできます）。



しかし、すべてのスロットが空いていない場合はどうなりますか？ Rubyヒープのページが多く、ガベージコレクターが異なる場所にあるオブジェクトを解放し、最終的には異なるページに多くの空きスロットがある場合はどうでしょうか。 この状況では、Rubyにはオブジェクトを配置するための空きスロットがありますが、メモリアロケーターとカーネルは引き続きメモリを割り当てます！

メモリ割り当ての断片化

メモリアロケーターにも同様の問題がありますが、まったく異なる問題があります。 システムヒープ全体を一度に解放する必要はありません。 理論的には、単一のシステムページを解放できます。 ただし、メモリアロケータは任意のサイズのメモリ割り当てを処理するため、システムページにいくつかの割り当てが存在する場合があります。 すべての選択が解放されるまで、システムページを解放できません。



3 KBの割り当てと2 KBの割り当てが2つのシステムページに分割されている場合はどうなるかを考えてください。 最初の3 KBを解放すると、両方のシステムページが部分的に占有されたままになり、解放できなくなります。



したがって、状況が失敗した場合、システムページには多くの空き領域がありますが、それらは完全には解放されません。

さらに悪いことは、空き場所がたくさんあるが、新しい割り当て要求を満たすのに十分な場所がない場合はどうでしょうか？ メモリアロケータは、まったく新しいシステムヒープを割り当てる必要があります。

Rubyヒープページの断片化がメモリの膨張を引き起こしていますか？

断片化がRubyでの過剰なメモリ使用を引き起こしている可能性があります。 もしそうなら、2つの断片化のどちらがより有害ですか？ これは...

1. Rubyヒープページの断片化？ または
   
2. メモリアロケーターの断片化？

最初のオプションは、チェックするのに十分簡単です。 Rubyは、 ObjectSpace.memsize_of_allとGC.stat 2つのAPIを提供します。 この情報のおかげで、Rubyがアロケーターから受け取ったすべてのメモリーを計算できます。



ObjectSpace.memsize_of_allは、すべてのアクティブなRubyオブジェクトが占有しているメモリを返します。 つまり、スロット内のすべてのスペースと外部データ。 上の図では、これはすべての青とオレンジのオブジェクトのサイズです。

GC.stat使用GC.statと、すべての空きスロットのサイズ、つまり上の図の灰色の領域全体を確認できGC.stat 。 アルゴリズムは次のとおりです。

 GC.stat[:heap_free_slots] * GC::INTERNAL_CONSTANTS[:RVALUE_SIZE] 

それらを要約すると、これはRubyが知っているすべてのメモリであり、Rubyヒープのページの断片化を伴います。 カーネルの観点から、メモリ使用量が多い場合、残りのメモリはRubyの制御外のどこか、例えばサードパーティのライブラリや断片化に行きます。

私は、それぞれがループ内の行を選択する多数のスレッドを作成する簡単なテストプログラムを作成しました。 しばらくしてからの結果は次のとおりです。



それは...ただ...クレイジーです！

結果は、Rubyが使用されるメモリの総量に非常に弱い影響を与えることを示しており、Rubyヒープのページが断片化されているかどうかは関係ありません。

他の場所で犯人を探す必要があります。 少なくとも今では、Rubyのせいではないことがわかっています。

メモリ割り当てフラグメンテーションの研究

別の容疑者はメモリアロケータです。 最終的に、Nate BerkopekとHerokuは、メモリアロケーター（jemallocの完全な置き換えまたは魔法の環境変数MALLOC_ARENA_MAX=2 ）をMALLOC_ARENA_MAX=2により、メモリ使用量が大幅に削減されることにMALLOC_ARENA_MAX=2 。

最初にMALLOC_ARENA_MAX=2が何をするのか、そしてなぜそれが役立つのかを見てみましょう。 次に、ディストリビューターレベルでフラグメンテーションを調べます。

過剰なメモリ割り当てとglibc

MALLOC_ARENA_MAX=2役立つ理由は、マルチスレッドによるものです。 複数のスレッドが同じシステムヒープから同時にメモリを割り当てようとすると、それらのスレッドはアクセスのために戦います。 一度に1つのスレッドのみがメモリを受信できるため、マルチスレッドメモリ割り当てのパフォーマンスが低下します。


システムヒープで動作できるスレッドは一度に1つだけです。 マルチスレッドのタスクでは、競合が発生し、その結果、パフォーマンスが低下します

このような場合のメモリアロケーターには、最適化があります。 彼はいくつかのシステムヒープを作成し、それらを異なるスレッドに割り当てようとします。 ほとんどの場合、スレッドは独自のヒープでのみ動作し、他のスレッドとの競合を回避します。

実際、この方法で割り当てられるシステムヒープの最大数は、デフォルトで仮想プロセッサの数に8を掛けた値に等しくなります。つまり、2つのハイパースレッドを持つデュアルコアシステムでは、それぞれ2 * 2 * 8 = 32システムヒープが生成されます！ これは私が過度の分配と呼ぶものです。

デフォルトの乗数がなぜそんなに大きいのですか？ メモリアロケーターの主要な開発者はRed Hatであるためです。 顧客は、強力なサーバーと大量のRAMを備えた大企業です。 上記の最適化により、メモリ使用量が大幅に増加するため、平均的なマルチスレッドパフォーマンスが10％向上します。 Red Hatのお客様にとって、これは良い妥協案です。 残りのほとんど-ほとんど。

彼女のブログとHerokuの記事でネイトは、システムヒープの数を増やすと断片化が増加し、公式ドキュメントを引用していると主張しています。 MALLOC_ARENA_MAX変数は、マルチスレッドに割り当てられるシステムヒープの最大数を減らします。 このロジックにより、断片化が減少します。

システムヒープの視覚化

システムヒープの数を増やすと断片化が増えるというNateとHerokuの声明は本当ですか？ 実際、メモリアロケーターレベルでの断片化に問題はありますか？ 私はこれらの仮定のどれも当たり前のものにしたくなかったので、研究を始めました。

残念ながら、システムヒープを視覚化するツールはないため、このようなビジュアライザを自分で作成しました 。

まず、何らかの方法でシステムヒープの分散スキームを保持する必要があります。 私はメモリアロケータのソースを研究し、それが内部的にメモリをどのように表現しているかを見ました。 次に、これらのデータ構造を反復処理し、スキーマをファイルに書き込むライブラリを作成しました。 最後に、彼はそのようなファイルを入力として受け取り、視覚化をHTMLおよびPNG画像（ ソースコード ）としてコンパイルするツールを作成しました。



特定のシステムヒープを視覚化する例を次に示します（さらに多くあります）。 この視覚化の小さなブロックは、システムページを表します。

• 赤色の領域は使用済みメモリセルです。
• 灰色は、コアに解放されない空き領域です。
• 核のために白い領域が解放されます。

視覚化から次の結論を引き出すことができます。

1. いくつかの断片化があります。 赤い斑点はメモリから散らばっており、一部のシステムページは半分だけ赤くなっています。
   
2. 驚いたことに、 ほとんどのシステムヒープには、完全に無料のシステムページ（グレー）が大量に含まれています。

そして、それは私に夜明けを告げました：

フラグメンテーションは問題のままですが、それはポイントではありません！

むしろ、問題は多くの灰色です：このメモリアロケーターはメモリをカーネルに送り返しません ！

メモリアロケータのソースコードを再検討した結果、デフォルトではシステムヒープの最後にシステムページのみがカーネルに送信され、 めったに送信されないことが判明しました 。 おそらく、このようなアルゴリズムはパフォーマンス上の理由で実装されています。

マジックトリック：割礼

幸いなことに、私は1つのトリックを見つけました。 メモリアロケータに、最後のカーネルページだけでなく、関連するすべてのシステムページの解放を強制するプログラミングインターフェイスが1つあります。 malloc_trimと呼ばれます 。

この機能については知っていましたが、役に立つとは思いませんでした。マニュアルには次のように書かれているからです。

malloc_trim（）関数は、ヒープの上部で空きメモリを解放しようとします。

マニュアルが間違っています！ ソースコードの分析によると、プログラムはトップだけでなく、関連するすべてのシステムページを解放します。

この関数がガベージコレクション中に呼び出されるとどうなりますか？ Ruby 2.6のソースコードを変更して、 gc_start関数でmalloc_trim()を呼び出します。 malloc_trim()例を示します。

 gc_prof_timer_start(objspace); { gc_marks(objspace, do_full_mark); // BEGIN MODIFICATION if (do_full_mark) { malloc_trim(0); } // END MODIFICATION } gc_prof_timer_stop(objspace); 

テスト結果は次のとおりです。



なんという大きな違いでしょう！ 簡単なパッチにより、メモリ消費がほぼMALLOC_ARENA_MAX=2削減されました。

ビジュアライゼーションでの外観は次のとおりです。



カーネルに解放されたシステムページに対応する多くの白い領域が表示されます。

おわりに

基本的に、断片化はそれとは無関係であることが判明しました。 最適化は依然として有用ですが、主な問題は、メモリアロケータがメモリをカーネルに戻すことを好まないことです。

幸いなことに、このソリューションは非常にシンプルでした。 主なものは根本原因を見つけることでした。

ビジュアライザーのソースコード

ソースコード

パフォーマンスはどうですか？

パフォーマンスは引き続き主要な懸念事項の1つです。 malloc_trim()呼び出しは無料ではできませんが、コードによると、アルゴリズムは線形時間で動作します。 そこで、Rails Ruby Benchベンチマークを立ち上げたNoah Gibbsに頼りました。 驚いたことに、このパッチによりパフォーマンスがわずかに向上しました。





それは私の心を吹き飛ばしました。 効果は理解できないが、ニュースは良い。

さらにテストが必要

この研究の一環として、限られた数の症例のみが検証されています。 他のワークロードへの影響が何であるかは不明です。 テストを支援したい場合は、 私に連絡してください 。