Истраживање Медиастреамер2 ВоИП механизма. Део 12

Материјал чланка је преузет са мог зен канал.

У последњих Чланак, обећао сам да ћу размотрити питање процене оптерећења тикера и начина да се изборимо са превеликим оптерећењем рачунара у медијском стримеру. Али одлучио сам да би било логичније да покријем питања отклањања грешака занатских филтера у вези са кретањем података и тек онда размотрим проблеме оптимизације перформанси.

Отклањање грешака у занатским филтерима

Након што смо у претходном чланку испитали механизам кретања података у медијском стримеру, логично би било говорити о опасностима које се крију у њему. Једна од карактеристика принципа „тока података“ је да се додела меморије из гомиле дешава у филтерима који се налазе на изворима тока података, а филтери који се налазе на крају путање тока већ ослобађају меморију са повратком на гомилу. Поред тога, стварање нових података и њихово уништавање може се десити негде у међутачкама. Генерално, ослобађање меморије се врши помоћу филтера који није онај који је креирао блок података.

Са становишта транспарентног праћења меморије, разумно би било да филтер приликом пријема улазног блока одмах након обраде уништи исти, ослобађајући меморију, а на излаз стави новонастали блок са излазним подацима. У овом случају, цурење меморије у филтеру би се могло лако пратити — ако је анализатор открио цурење у филтеру, онда филтер који га прати не уништава правилно долазне блокове и постоји грешка у њему. Али са становишта одржавања високих перформанси, овај приступ раду са блоковима података није продуктиван - доводи до великог броја операција за доделу / ослобађање меморије за блокове података без икаквог корисног исцрпљивања.

Из тог разлога, филтери медија стримера, како не би успоравали обраду података, приликом копирања порука користе функције које креирају светле копије (о њима смо говорили у претходном чланку). Ове функције само креирају нову копију заглавља поруке тако што на њега „прикаче“ блок података из копиране „старе“ поруке. Као резултат, два заглавља су повезана са једним блоком података и референтни бројач у блоку података се повећава. Али то ће изгледати као две поруке. Може бити више порука са таквим "јавним" блоком података, на пример, МС_ТЕЕ филтер генерише десет таквих светлих копија одједном, дистрибуирајући их међу својим излазима. Ако сви филтери у ланцу раде исправно, до краја цевовода овај број референци би требало да достигне нулу и биће позвана функција ослобађања меморије: мс_фрее(). Ако до позива не дође, онда се овај део меморије више неће враћати у гомилу, тј. он "цуре". Цена коришћења светлих копија је губитак могућности да се лако одреди (као што би било у случају коришћења обичних копија) у ком филтеру графа меморија цури.

Пошто одговорност за проналажење цурења меморије у "матичним" филтерима лежи на програмерима медијског стримера, онда највероватније нећете морати да их отклањате. Али са вашим филтером за израду, ви сте сами скакавац своје среће, а време које проведете тражећи цурење у вашем коду зависиће од ваше тачности. Да бисмо скратили ваше време за отклањање грешака, морамо да погледамо технике локализације цурења када дизајнирамо филтере. Осим тога, може се десити да ће се цурење манифестовати само при примени филтера у реалном систему, где број „осумњичених” може бити огроман, а време за отклањање грешака ограничено.

Како се манифестује цурење меморије?

Логично је претпоставити да у излазу програма врх ће показати све већи проценат меморије коју заузима ваша апликација.

Спољна манифестација ће се састојати у чињеници да ће у неком тренутку систем полако реаговати на кретање миша, полако прецртавајући екран. Такође је могуће да ће системски дневник расти и заузети простор на чврстом диску. У овом случају, ваша апликација ће почети да се понаша чудно, не реагује на команде, не може да отвори датотеку итд.

Да бисмо идентификовали чињеницу цурења, користићемо анализатор меморије (у даљем тексту анализатор). То може бити Валгринд (Добро чланак о томе) или уграђен у компајлер ГЦЦ МемориСанитизер или нешто друго. Ако анализатор покаже да се цурење јавља у једном од филтера графикона, то значи да је време да примените једну од метода описаних у наставку.

Метода три бора

Као што је горе поменуто, у случају цурења меморије, анализатор ће показати на филтер који је захтевао доделу меморије из гомиле. Али неће указати на филтер који је „заборавио” да га врати, што је, у ствари, криво. Дакле, анализатор може само потврдити наше страхове, али не и указати на њихов корен.

Да бисте сазнали локацију "лошег" филтера на графикону, можете ићи тако што ћете смањити графикон на минимални број чворова на којима анализатор још увек открива цурење и лоцира проблематични филтер у преостала три бора.

Али може се десити да смањењем броја филтера у колони пореметите нормалан ток интеракције између филтера и других елемената вашег система и цурење се више неће појављивати. У овом случају, мораћете да радите са графиконом пуне величине и користите приступ описан у наставку.

Метода клизног изолатора

Ради једноставности презентације користићемо граф који се састоји од једног ланца филтера. Она је приказана на слици.

Обичан графикон, у коме су, уз готове филтере медија стример, коришћена четири црафт филтера Ф1…Ф4, четири различита типа које сте давно направили и не сумњате у њихову исправност. Међутим, претпоставимо да неколико њих има цурење меморије. Када покрећемо наш програм за надзор анализатора, сазнајемо из његовог извештаја да је одређени филтер захтевао одређену количину меморије и да је није вратио у гомилу Н пута. Лако је претпоставити да ће постојати референца на функције интерног филтера типа МС_ВОИД_СОУРЦЕ. Његов задатак је да узме меморију са гомиле. Други филтери би требало да га врате тамо. Оне. наћи ћемо цурење.

Да би се утврдило на ком делу цевовода је дошло до неактивности која је довела до цурења меморије, предлаже се увођење додатног филтера који једноставно пребацује поруке са улаза на излаз, али истовремено ствара несветлу, нормалну „тешка“ копија улазне поруке, а затим потпуно брисање поруке која је стигла на излаз.улаз. Такав филтер ћемо назвати изолатором. Сматрамо да пошто је филтер једноставан, цурење у њему је искључено. И још једно позитивно својство - ако га додамо на било које место у нашем графикону, онда то ни на који начин неће утицати на рад кола. Филтер изолатора ћемо приказати као круг са двоструком контуром.

Омогућите изолатор одмах након филтера воидсоурсе:

Поново покрећемо програм са анализатором и видимо да ће овога пута анализатор окривити изолатор. На крају крајева, он је тај који сада ствара блокове података, који се затим губе непознатим немарним филтером (или филтерима). Следећи корак је померање изолатора дуж ланца удесно, за један филтер, и почетак анализе поново. Дакле, корак по корак, померајући изолатор удесно, добијамо ситуацију када се смањује број „процурелих“ меморијских блокова у следећем извештају анализатора. То значи да је у овом кораку изолатор завршио у ланцу одмах након проблематичног филтера. Ако је постојао само један "лош" филтер, онда ће цурење потпуно нестати. Тако смо локализовали проблематични филтер (или један од неколико). Након што смо „поправили“ филтер, можемо наставити да померамо изолатор удесно дуж ланца док се цурење меморије потпуно не елиминише.

Имплементација филтера изолатора

Имплементација изолатора изгледа баш као нормалан филтер. Датотека заглавља:

/* Файл 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)

Метода замене функција управљања меморијом

За суптилније истраживање, медијски стример пружа могућност замене функција приступа меморији сопственим, који ће поред главног рада снимати „Ко, где и зашто“. Три функције се замењују. Ово се ради на следећи начин:

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);

Ова карактеристика долази у помоћ у случајевима када анализатор толико успорава филтере да је поремећен рад система у којем је уграђено наше коло. У таквој ситуацији морате напустити анализатор и користити замену меморијских функција.

Размотрили смо алгоритам акције за једноставан граф који не садржи гране. Али овај приступ се може применити на друге случајеве, наравно уз компликације, али идеја остаје иста.

У следећем чланку ћемо размотрити питање процене оптерећења тикера и како се носити са превеликим оптерећењем рачунара у медијском стримеру.

Извор: ввв.хабр.цом