Mediastreamer2 VoIP エンジンを探索します。 パート12

記事の素材は私のものから引用しました 禅チャンネル.

過去に статье、ティッカーの負荷を評価する問題と、メディアストリーマーの過度のコンピューティング負荷に対処する方法を検討することを約束しました。 しかし、私は、データ移動に関連するクラフト フィルターのデバッグの問題を取り上げてから、パフォーマンスの最適化の問題を検討する方が論理的であると判断しました。

クラフトフィルターのデバッグ

前回の記事でメディア ストリーマー内でデータを移動するメカニズムを説明した後、それに隠された危険性について話すのは論理的でしょう。 「データ フロー」原理の特徴の XNUMX つは、データ フローのソースにあるフィルターのヒープからメモリが割り当てられ、フローの最後にあるフィルターによってメモリが解放されてヒープに戻されることです。パス。 さらに、新しいデータの作成とその破棄は、その中間のどこかで発生する可能性があります。 一般に、メモリの解放は、データ ブロックを作成したフィルターとは異なるフィルターによって実行されます。

透過的なメモリ監視の観点からは、フィルタが入力ブロックを受信すると、処理後に直ちにブロックを破棄してメモリを解放し、出力データを含む新しく作成されたブロックを出力するのが合理的です。 この場合、フィルター内のメモリ リークは簡単に追跡できます。アナライザーがフィルター内のリークを検出した場合、次のフィルターは受信ブロックを適切に破棄せず、エラーが発生します。 しかし、高いパフォーマンスを維持するという観点から見ると、データ ブロックを操作するこのアプローチは生産的ではありません。有用な出力が得られずに、データ ブロックにメモリを割り当てたり解放したりするための多数の操作が必要になります。

このため、メディア ストリーマー フィルターでは、データ処理が遅くならないように、メッセージをコピーするときに簡単にコピーを作成する機能が使用されます (前回の記事で説明しました)。 これらの関数は、コピーされる「古い」メッセージのデータ ブロックをメッセージ ヘッダーに「添付」することによって、メッセージ ヘッダーの新しいインスタンスを作成するだけです。 その結果、XNUMX つのデータ ブロックに XNUMX つのヘッダが付加され、データ ブロック内の参照カウンタがインクリメントされます。 ただし、XNUMX つのメッセージのように見えます。 このような「ソーシャル化された」データ ブロックにはさらに多くのメッセージが存在する可能性があります。たとえば、MS_TEE フィルターはそのようなライト コピーを一度に XNUMX 個生成し、出力間で分散します。 チェーン内のすべてのフィルターが正しく動作する場合、パイプラインの終わりまでに、この参照カウンターはゼロに達し、メモリー解放関数が呼び出されます。 ms_free()。 呼び出しが発生しない場合、このメモリ部分はヒープに戻されなくなります。 「漏れる」ことになります。 ライト コピーを使用する代償として、(通常のコピーの場合と同様に) どのグラフ フィルターがメモリ リークを発生させているかを簡単に判断する機能が失われます。

メディア ストリーマーの開発者はネイティブ フィルターのメモリ リークを見つける責任があるため、ほとんどの場合、デバッグする必要はありません。 しかし、クラフト フィルターを使用すると、自分自身の幸福をバッタバッタにすることになり、コード内のリークの検索に費やす時間は精度に依存します。 デバッグ時間を短縮するには、フィルターを開発するときにリーク検出技術を検討する必要があります。 さらに、フィルタが実際のシステムに適用された場合にのみリークが現れる可能性があります。その場合、「容疑者」の数は膨大であり、デバッグの時間は限られている可能性があります。

メモリリークはどのようにして現れるのでしょうか?

プログラム出力で次のように仮定するのは論理的です top アプリケーションが占有するメモリの割合の増加が表示されます。

外部の症状としては、ある時点からシステムがマウスの動きにゆっくりと反応し始め、ゆっくりと画面が再描画されるようになります。 システム ログが増大し、ハード ドライブのスペースを消費する可能性もあります。 この場合、アプリケーションはコマンドに応答しなくなったり、ファイルを開けなくなったりするなど、奇妙な動作をし始めます。

リークの発生を検出するには、メモリアナライザ（以下、アナライザ）を使用します。 かもしれない ヴァルグリンド （良い 記事 それについて)、またはコンパイラに組み込まれています gccの メモリーサニタイザー または他の何か。 アナライザーがグラフ フィルターの XNUMX つでリークが発生していることを示した場合は、以下で説明する方法のいずれかを適用する時期が来たことを意味します。

スリーパインズ工法

前述したように、メモリ リークが発生した場合、アナライザーはヒープからのメモリ割り当てを要求したフィルターを指します。 しかし、フィルターを返すことを「忘れた」フィルター、実際にはそれが原因であることは指摘されません。 したがって、分析者は私たちの恐怖を確認することしかできませんが、その根源を示すことはできません。

グラフ内の「不良」フィルターの位置を見つけるには、アナライザーが依然としてリークを検出するノードの最小数までグラフを減らし、問題のあるフィルターを残りの XNUMX つのピンに特定します。

ただし、グラフ内のフィルターの数を減らすと、フィルターとシステムの他の要素の間の通常の相互作用が中断され、リークが発生しなくなる場合があります。 この場合、フルサイズのグラフを操作し、以下に概説するアプローチを使用する必要があります。

スライドインシュレーター方式

表現を簡単にするために、XNUMX つのフィルター チェーンで構成されるグラフを使用します。 彼女が写真に写っています。

既製のメディア ストリーマ フィルターに加えて、1 つの異なるタイプの 4 つのクラフト フィルター FXNUMX...FXNUMX が使用されている通常のグラフ。これは、ずっと前に作成したもので、その正確さに疑いの余地はありません。 ただし、そのうちのいくつかにメモリ リークがあると仮定します。 プログラムを実行してアナライザーを監視すると、そのレポートから、特定のフィルターが一定量のメモリを要求し、それをヒープに N 回返しなかったことがわかります。 MS_VOID_SOURCE タイプの内部フィルター関数へのリンクがあることは容易に推測できます。 彼の仕事は、ヒープからメモリを取得することです。 他のフィルターはそれをそこに返す必要があります。 それらの。 漏洩の事実を発見します。

パイプラインのどのセクションでメモリ リークにつながる非アクションがあったのかを判断するには、単にメッセージを入力から出力にシフトするだけでなく、同時にライトではない入力メッセージのコピーを作成する追加のフィルターを導入することが提案されています。 、むしろ通常の「重い」メッセージであり、その後、入り口で受信したメッセージを完全に削除します。 このようなフィルターを絶縁体と呼びます。 簡易フィルターですので漏れはないと思います。 そして、もう XNUMX つの肯定的な特性があります。これをグラフのどこかに追加しても、回路の動作にはまったく影響しません。 フィルタアイソレータを二重回路を持つ円の形で描きます。

voidsource フィルターの直後にアイソレーターをオンにします。

アナライザーを使用してプログラムを再度実行すると、今度はアナライザーが絶縁体のせいであることがわかります。 結局のところ、データのブロックを作成しているのは彼であり、その後、未知の不注意なフィルターによって失われます。 次のステップでは、チェーンに沿って絶縁体をフィルター XNUMX つ分右に移動し、解析を再度開始します。 したがって、アイソレータを段階的に右に移動すると、次のアナライザ レポートで「リーク」メモリ ブロックの数が減少する状況が得られます。 これは、このステップでは、インシュレーターが問題のあるフィルターの直後のチェーンにあったことを意味します。 「不良」フィルターが XNUMX つだけであれば、漏れは完全になくなります。 したがって、問題のあるフィルター (または複数のうちの XNUMX つ) を特定しました。 フィルタを「修正」したら、メモリ リークを完全に克服するまで、チェーンに沿ってアイソレータを右に移動し続けることができます。

アイソレータフィルターの実装

アイソレータの実装は通常のフィルタとまったく同じように見えます。 ヘッダーファイル:

/* Файл iso_filter.h  Описание изолирующего фильтра. */

#ifndef iso_filter_h
#define iso_filter_h

/* Задаем идентификатор фильтра. */
#include <mediastreamer2/msfilter.h>

#define MY_ISO_FILTER_ID 1024

extern MSFilterDesc iso_filter_desc;

#endif

フィルター自体:

/* Файл iso_filter.c  Описание изолирующего фильтра. */

#include "iso_filter.h"

    static void
iso_init (MSFilter * f)
{
}
    static void
iso_uninit (MSFilter * f)
{
}

    static void
iso_process (MSFilter * f)
{
    mblk_t *im;

    while ((im = ms_queue_get (f->inputs[0])) != NULL)
    {
        ms_queue_put (f->outputs[0], copymsg (im));
        freemsg (im);
    }
}

static MSFilterMethod iso_methods[] = {
    {0, NULL}
};

MSFilterDesc iso_filter_desc = {
    MY_ISO_FILTER_ID,
    "iso_filter",
    "A filter that reads from input and copy to its output.",
    MS_FILTER_OTHER,
    NULL,
    1,
    1,
    iso_init,
    NULL,
    iso_process,
    NULL,
    iso_uninit,
    iso_methods
};

MS_FILTER_DESC_EXPORT (iso_desc)

メモリ管理機能の置き換え方法

より微妙な調査のために、メディア ストリーマーはメモリ アクセス機能を独自のものに置き換える機能を提供し、主な作業に加えて、「誰が、どこで、なぜ」を記録します。 XNUMXつの機能が置き換えられます。 これは次のように行われます。

OrtpMemoryFunctions reserv;
OrtpMemoryFunctions my;

reserv.malloc_fun = ortp_malloc;
reserv.realloc_fun = ortp_realloc;
reserv.free_fun = ortp_free;

my.malloc_fun = &my_malloc;
my.realloc_fun = &my_realloc;
my.free_fun = &my_free;

ortp_set_memory_functions(&my);

この機能は、アナライザがフィルタの動作を遅くしすぎて、回路が構築されているシステムの動作が中断される場合に役立ちます。 このような状況では、アナライザーを放棄し、メモリを操作する関数の代替を使用する必要があります。

分岐を含まない単純なグラフのアクションのアルゴリズムを検討しました。 ただし、このアプローチは、もちろんより複雑になる他のケースにも適用できますが、考え方は同じです。

次の記事では、ティッカーの負荷を見積もる問題と、メディア ストリーマーの過度のコンピューティング負荷に対処する方法について説明します。

出所： habr.com