1つのサーバーアプリケーションでのメモリリークについて

このノートを読んだ後、FreeBSDのサーバーアプリケーションで予期しないメモリリークが発生した後に何を経験しなければならないかがわかります。 そのような問題を検出する現代の手段はこの環境に存在し、それらの最も強力なものが曲がった手では完全に役に立たないのはなぜですか。



木曜日のある午後、Zabbixは50台のサーバーのうち5台がスワップセクションのスペース不足の通知を送信しました。 CPVD（空きメモリ）のグラフは、問題の規模を明確に示しています（右側のマウンドは、スワップでの混雑によるメモリの解放です）。 幸いなことに、金曜日が先にあり、週末に落ち着いてすべてを修正できます。 その瞬間、誰も原因を見つけて排除するのに6日以上かかるとは想像もしていませんでした。



サーバーについて。 8 GBのメモリを搭載した10年目から11年目の世代の一般的なサーバー（ほぼ完全に同一で、同じブランドのものでも）。 サーバーはグループに分けられ、さまざまなユーザーアカウントのセットを提供します。



アプリケーションについて。 広告サーバー、C \ C ++ロジックを備えたHTTP（libh2o）、多数のサードパーティライブラリ、共有メモリ内の標準C ++コンテナのような自転車など 着信要求を受け入れ、複数のアップストリームサーバーにリダイレクトし、応答のオークションを開催して、クライアントに応答を返します。 すべてがFreeBSD 11.0 \ 11.1を有効にします。

誰のせいですか？

コードベースの最後の変更は約10日前で、最近はメモリに目立った変化はありませんでした。 大まかな分析により、最も可能性の高い理由のリストが得られました。

• 着信/発信リクエストの質的または量的特性が変更され、メモリの割り当て/解放でエラーが発生しました。
• 共有メモリにコンテナがある自転車。 何かがうまくいかない場合、彼らは常に疑念を引き起こします。
• リークはなく、データが増えただけで、中断が停止しました。
• OS \ライブラリのカーネルを更新した結果。 しかし、デフォルトの自動更新はありません。何らかの種類のWindowsではありません。必要なときにいつでも更新をロールアップし 、さらにマシンを再起動できます。 数ヶ月前、近隣プロジェクトの多くのサービスが崩壊しました。
• 誰かが標的ネットワーク攻撃を実行してオーバーフローを引き起こします。
• メルトダウン\スペクター。 はい！ もちろんです。 減速を恐れて更新を行ったことは覚えていませんが、今日のそのようなポイントには、緊急事態が発生する場所がなければなりません。

ただし、要求/応答の特性は変更されていません（少なくとも収集されたすべてのメトリックで）。 これ以上データはなく、ネットワークは整然としており、多くの空きリソースがあり、サーバーはすぐに応答します...外部環境は変更されましたか？

どうする

数年前に似たようなものが表面化したが、問題を解決するのに役立つほとんどすべてのツールは忘れられた。 私はほんの数時間でそれを取り除きたかったので、最初の素朴な試みはStackOverflowへの答えを見つけることでした...基本的に、人々はValgrindといくつかの未知の工芸品（明らかに著者自身）、またはVisualStudioのプラグイン（関連なし）をお勧めします。 クラフトはほとんどすべてのものに落ち、適切に動作し始めることさえありませんでした（memleax、ElectricFenceなど）。詳細については説明しません。



途中で、最近リリースされたすべての機能を思い出します。幸いなことに、先月、主な機能の変更はほとんどありませんでした-GeoIPベースのねじ込みなど、詳細に...



クライアントと上位サーバーを1つずつ切断しようとしています（この方法は最初の方法の1つでしたが、何らかの理由で結果が得られず、さまざまな強度の組み合わせでリークが発生し、着信要求への線形依存のみが観察されました）。



すぐに、2か月前の監査まで、古いバージョンにロールバックする試みが行われました。 そこでメモリがリークし続けました。 他のコンポーネントとの互換性がないため、以前のバージョンにロールバックすることはできませんでした。



主な質問は、なぜこれらの5つのサーバーですか？ すべてのマシンはほぼ同じです（OSバージョン11 \ 11.1の違いを除く）。 この問題は、特定のアカウントグループでのみ発生します。 他の人にはそのような動作のヒントはありません。つまり、着信要求に正確に依存している必要があります...





何らかの理由で、私はすべてを美しく行いたい、つまり普遍的な手段でリークポイントを見つけたいと思いました。 おそらく、これは初期段階で犯した主な間違いの1つでした。

それで、今日説明されている問題を解決するための普遍的な救済策は何ですか？ 基本的に、これらはmalloc \ freeへの呼び出しをラップし、すべてのメモリ操作を監視するサードパーティライブラリです。

valgrind

問題を検出する優れた方法。 実際、ほぼすべてのタイプ（ダブルリリース、境界を越える、リークなど）をキャッチします。 この物語はそれが始まる前に終わっていたでしょう。 しかし、valgrindには1つの問題があります。負荷の高いアプリケーションにはほとんど完全に役に立たないということです。 次のように見えます。プログラムは通常よりも20〜50倍長く起動しますが、それでも動作します。もちろん、ほとんどのリクエストには、タイムアウトしてタイムアウトする時間はありません。 CPUコアは100％でロードされますが、アプリケーションは有用なアクションを実行せず、valgrind仮想マシン上のすべてのリソースを消費します。 ログを見ると、正常に送信されるすべてのリクエストの何パーセントかの悲惨な部分が見つかります。 Ctrlキーを押しながらCキーを押すと、運が良ければ数分でログが表示されるか、すべてが落ちます（多くの場合、2番目のログ、またはほとんど空のログがありました）。 一般的に、それは離陸しませんでした。

tcmalloc

ライブラリはgoogle-perftoolsポートからアクセスできます。 開発者によると ：

これは、Googleで使用するヒーププロファイラーです。

ほとんどのこのようなツールと同様に、環境変数（LD_PRELOAD）を使用するか、ライブラリ自体をコンパイルする（-ltcmalloc）ことにより接続されます。 どちらの方法も機能しませんでした。 プロセスで別のプロセスが発見されました-コードから静的メソッドHeapLeakChecker :: NoGlobalLeaks（）を呼び出します。 しかし、何らかの理由で、どのライブラリバージョンにもエクスポートされませんでした。 後で判明 ：

[FreeBSD上] libtcmalloc.soは正常にビルドされ、「高度な」tcmalloc機能はすべて、Linux固有のコードを持つリークチェッカーを除いてすべて機能します。

:(さらに進んでいきましょう。

リブメム

umemポートから利用可能。 メモリの問題を検出するスマートな方法。 特にMDBとの組み合わせで 。 残念ながら、これらはすべてSolaris OSでのみ利用可能であり、FreeBSD MDB に移植することをお勧めします。 アプリケーションを起動できませんでした。 起動時に、mainを呼び出す前に、libthr.soからcallocが呼び出されます。libthr.soはすでにlibumemによってインターセプトされています。 次に、libumemはコード内のスレッドで作業を初期化しようとします。 再帰-s。 一般に、メインコールのかなり前のスタックは次のようになります。







卵と鶏肉の典型的な問題。これはどのように移動するか明確ではありません。 マルチスレッドをカットするというアイデアを延期することにしました（残念ながら、ブーストの依存関係とgetaddrinfoのラッパーでのみ使用しています）。 まあ、誰かが開いた同様のチケットで開発者（まだ生きている場合）に書き込み、続けます。

dmalloc

同じ名前のポートから利用できます。 優れたドキュメントがあります。 起動時のスタックは驚くほど前のケースに似ています：

(gdb) bt #0 0x0000000802c8783e in dmalloc_malloc () from /usr/local/lib/libdmallocthcxx.so.1 #1 0x0000000802c88623 in calloc () from /usr/local/lib/libdmallocthcxx.so.1 #2 0x00000008038a8594 in ?? () from /lib/libthr.so.3 #3 0x00000008038a98d4 in ?? () from /lib/libthr.so.3 #4 0x00000008038a58fa in pthread_mutex_lock () from /lib/libthr.so.3 #5 0x0000000802c87641 in ?? () from /usr/local/lib/libdmallocthcxx.so.1 #6 0x0000000802c87bb3 in ?? () from /usr/local/lib/libdmallocthcxx.so.1 #7 0x0000000802c8787a in dmalloc_malloc () from /usr/local/lib/libdmallocthcxx.so.1 #8 0x0000000802c88623 in calloc () from /usr/local/lib/libdmallocthcxx.so.1 #9 0x00000008038a8594 in ?? () from /lib/libthr.so.3 #10 0x00000008038a98d4 in ?? () from /lib/libthr.so.3 #11 0x00000008038a58fa in pthread_mutex_lock () from /lib/libthr.so.3 #12 0x0000000802c87641 in ?? () from /usr/local/lib/libdmallocthcxx.so.1 #13 0x0000000802c87bb3 in ?? () from /usr/local/lib/libdmallocthcxx.so.1 #14 0x0000000802c8787a in dmalloc_malloc ()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、ここで著者は問題を認識しており、独自の回避策を提供しています：起動時に、無視する必要があるmalloc呼び出しの数を設定します（再帰を回避するため）。

プログラムがすぐにコアダンプする場合は低すぎること、dmallocライブラリが値が低いにもかかわらず再帰的であると言っている場合は高すぎることがわかっているため、いずれかの問題が発生する可能性があります。

いいね コアダンプと再帰の間にタグを付けて大切な数字を拾い、この事業全体を分析することが決定されました。



その間、サーバーのメモリはさらに速く使い果たされ始めました。 完全に食べる5〜6時間前の場合、1時間で完全に記憶が失われます。 cronを微調整する必要がありました（さらに、問題が発生しやすいサーバーのセットが成長し始めました。しかし、新しいサーバーのセットのメモリは24時間以内に使い果たしました。さらに、ほとんどのマシンでは、目に見えるメモリの問題はまったくありませんでした。



同時に、DCのエンジニアは、「このデータが増えた」という理論をテストするために、サーバーの1つに追加のメモリを要求しました（これがリークではないことを確認する最後の必死の試み）。 DCはすぐに追加の8GBを提供しましたが、これは夜間に安全に食べられました。 リークの存在を疑う人はいませんでした。

dtrace

冷酷なグッグルズの過程で、神秘的なD言語の神秘的なスクリプトがますます登場し始めました。それらはすべて、ほとんどすべてのコードの分析とデバッグにおけるIDDQDの一種であるdtraceという非常にクールなシステムユーティリティ用に設計されていることがわかりました。 私は彼について多くのことを聞きましたが、戦闘には使えませんでした。



つまり たとえば、malloc \ freeなどの特定のlibc関数へのすべての呼び出しを保存し、プローブを配置し、途中で一般的な統計を収集し、さらに数行のコードで分布図を作成することもできます。 たとえば、次のように：

 sudo dtrace -n 'pid$target::malloc:entry { @ = quantize(arg0); }' -p 15034
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

-実行中のプロセスで割り当てられたブロックの分布を調べることができます（例-pid = 15034）。 数秒の監視でアプリケーションの分布は次のようになります。

 value ------------- Distribution ------------- count 2 | 0 4 | 1407 8 | 455 16 |@@ 35592 32 |@@@@@@@@@@@@@@@@ 239205 64 |@@@@@@@ 112358 128 |@@@@ 55813 256 |@@@@@@ 91368 512 |@ 17204 1024 |@ 19751 2048 |@@ 33310 4096 | 2082 8192 | 554 16384 | 15 32768 | 0 65536 | 3960 131072 | 0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

いいですね 再コンパイルせずに、このすべてをオンザフライで！ 私たちはすべての秘密を解き明かすことに非常に近いところにいなければなりません。



また、アプリケーションからエクスポートされた関数の統計を収集することもできます！ ただし、コンパイルオプション-O1以上を使用すると、ほとんどの興味深い関数がエクスポートから簡単に消え、コンパイラーはそれらをコードに「インライン化」し、「サンプル」を配置するものがなくなります。



dtraceの謝罪者であるブレンダングレッグは、これらすべての狂気の日々の教師および指導者になりました。

場合によっては、この[dtrace]は優れたツールではなく、唯一のツールです。

彼は宣言した。



必要なものに似たものがありますが、ブレンダンはコメントを残しました。

FreeBSD：DTraceはSolarisと同様に使用できます。 機会があれば、例を共有します。

今日まで、残念なことに、この事件は彼には起こらなかった。 しかし、実際には、すべてはSolarisと同じであり、sbrkの代わりにmmap \ munmapのみが呼び出されます。



私はD言語の知恵を掘り下げなければなりませんでしたが、たとえば、特に集約された値のキャストなど、多くの分野を打ち負かすことはできませんでした。



最初に、 ここから少しやり直したスクリプトを試すことにしました ：





それは非常に単純に見えます：malloc \ freeへのすべての呼び出しとそれらの呼び出しの場所を保存します。 mallocでは-アドレスのカウンターを増やし、freeでは-減らします。 次に、受信したログを調べて、リーク（counters> 0のアドレス）を見つけます。 全体的な問題は、1秒あたり約150K mallocsで、ustack（）関数（スタック、つまり呼び出しの場所を保存する）がプロセス全体をその重みで文字通り埋め始めることです（valgrindの場合と同様）。 出力からスタックを削除し、アドレスとカウンターを単純に収集しようとしましたが、その結果、何らかの理由で、多くのカウンターがマイナスに深くなっています（実際には、台無しにされたヒープとダブルリリースですか？）、そして、実際には正のカウンター値を持つアドレスはありませんでした...同時に、dtrace次のような吐き出しエラー：

 dtrace: 3507 dynamic variable drops with non-empty dirty list dtrace: 2133 dynamic variable drops dtrace: 120 dynamic variable drops with non-empty dirty list dtrace: 993 dynamic variable drops dtrace: 176 dynamic variable drops with non-empty dirty list dtrace: 1617 dynamic variable drops dtrace: 539 dynamic variable drops with non-empty dirty list dtrace: 10252 dynamic variable drops dtrace: 3830 dynamic variable drops with non-empty dirty list dtrace: 17048 dynamic variable drops dtrace: 39483 dynamic variable drops dtrace: 1121 dynamic variable drops with non-empty dirty list dtrace: 35067 dynamic variable drops dtrace: 32592 dynamic variable drops dtrace: 10081 dynamic variable drops with non-empty dirty list
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、スタック上の壊れたアドレスに関するメッセージがちらつくことがよくありました。



これは、すべてのイベントを正しく処理する時間がなかったため、カウンターがマイナスになっていることを示唆しています...または、これはヒープ/スタックの問題です。 さらに、mallocsの1.5倍の無料の呼び出しがありました（つまり、ダブルリリースですか？）。



私はdtraceメーリングリストに助けを求めることにしました。







アーカイブから判断すると、かつて忙しかったニュースレターはつらい時期を迎えていました。 驚いたことに、最初の数分で答えが出ましたが、2人の参加者しか反応しませんでした。 保存するスタックフレームの数を指定する引数ustack（nframes）を使用することをお勧めします。 これは助けにならず、ustack（1）でさえプロセス全体を強制終了しました。 また、libumemを使用するようにアドバイスされました（おそらく、Solarisでクロールしたと思われます）。



その後、次のような非体系的な試みが行われました。mallocsによって割り当てられたサイズに関する統計を収集し、センサーの頻度を何らかの方法で減らすために、特定のサイズのみをフィルターで除外しようとしました。 無駄に、ustack（）は、1秒あたり最大100コールなど、最も最小の負荷向けに設計されているように感じられます。 または、リクエストごとにスタックをスピンさせずに、結果を無限の内部バッファに保存して、正しくクックできるようにする必要があります。 しかし、残念ながら、これには至りませんでした。



私は反対側からタスクにアプローチしようとしました-コード内のすべてのオブジェクトのデザイナとデストラクタの呼び出しをカウントするために、実際にスタックを保存する必要はありません。 これも結果を生み出しませんでした。 矛盾は明らかになりませんでしたが、もちろん、コード内のすべてのオブジェクトを「テスト」するのは面倒で、疑わしいものに限定しました。





すべてが風車との戦いに似始めました。



一般的に、dtraceの出力は、リークではなく、破損したヒープ/ダブルリリースであると主張しました。 これが本当なら、特別なものなしで、すべてが非常に悪いです。 ライブラリは十分ではありません。

しかし、これはすべて完全なナンセンスであることが判明し、数日間だけ標的から側に逃げました。

jemalloc

FreeBSD自体が非常にクールで高度なメモリマネージャを使用していることは注目に値します。 むしろ、私はそれを完全に忘れていました... 設定とオプションの数によって、他のすべてのラッパーライブラリは近くにさえありませんでした。 ドックをいじくり回した後、私はオプションでアプリケーションを起動することができました：

 setenv MALLOC_CONF utrace:true
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、 ここからの指示に従って、すべてのメモリ操作のログを収集（ktrace）および生成（kdump）します。 その中には記事のスクリプトでは機能しなかったreallocがあり、コメントからのスクリプトの2番目のバージョン （reallocを正しく処理する）は存在しないページにつながりました（そしてWayback Machineでも何も見つかりませんでした）。 reallocsのサポートを追加する必要がありましたが、実際には、リークが発生している可能性のある場所に大量のポインタを提供するだけで、どこに誰が割り当てられているかについてのヒントはありませんでした。

近くのトレース出力をざっと調べることで、ソースのリークの場所についてもう少し理解できるかもしれません:-)

-記事の著者を冗談を言った。



他のjemallocオプションが機能するためには（たとえば、二重解放の検出、配列からの脱出、メモリへのアクセスに関する拡張統計など）、コア全体が余分に必要です。 オプション、または現在のOSアセンブリ（人間から理解できたもの）。 しかし、それは検索の6日目であり、jemallocのさらなる掘り下げは中断されることになりましたが、このトピックは非常に興味深いものであり、私はそれに戻りたいと思います（同様の状況ではないことを望みます）。

最終的にリークの発見に役立ったもの

各モジュールとアプリケーションサブシステム、およびそれらの組み合わせを順番に無効にします。 私は最初からこの方法で行っていましたが、問題は1日以内に解決しましたが、見逃してはならない新しい興味深いものがいくつありました！



すべての悲しい物語には、肯定的な側面がなければなりません。

ポジティブのノート

• 針を検索する過程で、多くの小さな（そしてそうではない）バグ、主にメモリ割り当てが修正されました。
• ARC ZFSを削除しました（ディスクに何も書き込まず、メモリのみを消費し、 非常に重要な HTTPサーバーで必要な理由）。
• C ++の世界からの仮想デストラクタおよびその他のトリッキーなピースに関する記事が研究されました。
• Dで多数のスクリプトを使用して作成された、数え切れないほどのチュートリアルが（dtraceによって）表示されています。
• malloc \ freeのさまざまな実装に没頭し、アリーナとスラブの概念に精通している。
• プロジェクトで使用されているすべてのサードパーティライブラリのメモリに関連する既知のバグをすべて調査しました。
• Solaris OSが存在する最後の年に展開した歴史とドラマを学びました。
• GDBスキルのアップグレード/復元。

完全な絶望の瞬間に陥るべきでない狂気

• すべてを送ってLinuxに移行します。 この考えは、完全なGoogle Chrome、Skype、またはクールな自作システムユーティリティの不足が原因で、FreeBSDの熱心なサポーターを繰り返し訪れていると思います 。 パニックに陥らないでください。遅かれ早かれすべての問題が解決され、お気に入りのOSに再び戻ります。
• hex-viewerをスワップパーティションにクロールしようとします（メモリからプッシュされているものを確認し、リークの場所を推測しようとします）。
• アプリケーションからすべてのマルチスレッドを削除して、ほとんどの資金がより高く稼がれるようにしました。
• プロのフリーランサーを雇って、すべてをすばやく修正します。

結論

• リリースのすべての変更を徹底的に記録します。 ほとんどすべての場合、リークは最新のコミットの1つに関連付けられます。 あなたが非常に不運なら、最後の数ヶ月にわたってコミットしてください。 すべての変更を一度に1つずつロールバックし、組み合わせて、すべての変更を数回再確認してください。 わずかな間違い-そして、あなたは間違った方向に数日間/数週間連れ去られます。
• 時間が貴重な場合-特に高負荷のプロジェクトでは、汎用リーク検出ツールを使用しないでください。
• dtraceの巧妙さは十分ではなく、すべてのリクエストのごく一部しか処理できませんでした。 ただし、ここでの事後処理では、誤検出などを正しく除外する必要があります。 残念ながら、このアプローチを習得するのに十分な時間とエネルギーがありませんでした。

この物語の終わりは大きな運だと思います。 漏れが検索全体で安定して再現されたことは幸運でした。 リリースサーバーの1つで再構築されたアプリケーションを、ユーザーに大きな損害を与えることなく必要な回数だけ再起動する機会があったこと。 バグがリリースされてから問題が発生するまでに、問題を見つける可能性がゼロになると半年ではなく、わずか数日しかかかりませんでした...

質疑応答

結局のところ、漏れの原因は何だったのでしょうか？

前述のように、サーバーは上位サーバーの応答間でオークションを開催します。 回答が最大値を超える場合、それらは「クリッピング」されます（上位N個の結果が取得されます）。

上部はstd :: listに格納されます。ここで、要素はbidオブジェクトへのポインターです。 コミットの1つで、トップをトリミングするためのすばらしいコードlist.resize（max_results）が導入されました。 ご想像のとおり、list.resizeはポインター要素でdeleteを呼び出しません。 resizeを呼び出す前に、ハンドルを使用してすべての余分なポインターのメモリを解放する必要があります。



バグバージョンのリリース後、なぜそんなに長い間リークが感じられなかったのですか？

サーバーの応答は常に上位Nの結果になり、何も切り捨てられませんでした。 ある時点で特定のユーザーがより多くの回答を持ち、トップとの干渉をやめたということです。



以前のバージョンにロールバックしなかったため、問題をすぐに特定できなかったのはなぜですか？

ここで演じられたのはヒューマンファクターです。 実際には、アプリケーションは開始時にメモリを積極的に消費し始め、数時間強度を低下させます。 恐らく、検索の最中に、これは継続的なリークとして認識され、問題箇所を特定できませんでした。



サーバーの特定の部分でのみ問題が発生したのはなぜですか？

このサーバーグループでサービスを提供するアカウントのため。 オークションに参加した一部の企業は、上位に収まらない大量の入札を返し始めました。 他のサーバーが提供する他のアカウントについては、すべての応答がトップオークションに含まれていたか、最大値を超えることはほとんどありませんでした。 リストサイズ。



特にJavaで、リークに対処するストーリーを教えてください。 「N分ごとにアプリケーションを再起動する」方法は、普遍的なソリューションとして非常に人気がありますか？ Linuxや「tcmalloc and co」ではとても悲しいのですか。



UPD1 ：このテキストの準備中に、 clangを使用してリークを検出できる可能性に偶然出くわしました。



最後まで読んでくれたみんなに感謝します！