Vi lär oss VoIP-motorn Mediastreamer2. Del 12

Artikelmaterialet är hämtat från min Zen-kanal.

Tidigare artikeln, jag lovade att överväga frågan om belastningsbedömning av tickern och metoder för att hantera överdriven datorkraft i mediastreamern. Men jag beslutade att det skulle vara mer logiskt att belysa frågor om felsökning av skräddarsydda filter, relaterade till datarörelser, och först därefter ta upp frågor om prestandaoptimering.

Felsökning av skräddarsydda filter

Efter att vi i den föregående artikeln diskuterade mekanismen för datarörelser i mediastreamern, vore det logiskt att prata om de faror som döljer sig inom den. En av särdragen med principen "data flow" är att minnesallokeringen från heapen sker i filter som ligger vid källan till datastreamen, medan frigöring av minnet med återlämning till heapen görs av filter som är placerade i slutet av datastreamen. Dessutom kan skapandet och destruktionen av nya data ske någonstans i intermediära punkter. I allmänhet utförs minnesfrigöring inte av det filter som skapade datablocket.

Ur perspektivet av transparent övervakning av minnet skulle det vara rimligt att filter, när de får en ingångsblock, efter bearbetning omedelbart förstör det och frigör minnet, medan de på utsidan skulle presentera det nyligen skapade blocket med utdata. I det här fallet skulle minnesläckan i filtret lätt kunna spåras — om analysatorn upptäckte en läcka i filtret, innebär det att nästa filter efter det inte förstör ingångsblocken på rätt sätt och att det är en fel i det. Men med avseende på att upprätthålla hög prestanda, är en sådan metod för att hantera datablokkar, inte produktiv — den leder till ett stort antal operationer för allokering/frigöring av minne för datablokkar utan något nyttigt utbyte.

Av denna anledning använder mediastreamerfilter funktioner som skapar lätta kopior vid kopiering av meddelanden för att inte sakta ner databehandlingen (vi har berättat om dem i vår tidigare artikel). Dessa funktioner skapar bara en ny instans av meddelandets rubrik genom att "fästa" en datablack från det kopierade "gamla" meddelandet till den. Som ett resultat är två rubriker kopplade till en enda datablack och referensräknaren i datablocket ökas. Men detta kommer att se ut som två meddelanden. Det kan finnas fler meddelanden med en sådan "delad" datablack; till exempel genererar filtret MS_TEE genast ett dussin av dessa lätta kopior och fördelar dem över sina utgångar. Vid korrekt funktion av alla filter i kedjan, bör denna referensräknare nå noll i slutet av processen, och funktionen för minnesfrisättning kommer att anropas: ms_free(). Om anropet inte sker, betyder det att detta minnesblock redan inte kommer att återgå till högen, det vill säga det kommer att "läcka". Priset för att använda lätta kopior är förlusten av möjligheten att enkelt identifiera (som det skulle vara med vanliga kopior) i vilket filter minnet läcker.

Eftersom ansvaret för att upptäcka minnesläckor i "inbyggda" filter ligger på utvecklarna av mediastreamern, kommer du troligen inte att behöva felsöka dem. Men med ditt egenutvecklade filter är du själv smeden av din lycka, och din noggrannhet kommer att påverka den tid du lägger på att leta efter läckor i din kod. För att minska din tid vid felsökning bör vi överväga tekniker för att lokalisera läckor vid filterutveckling. Dessutom kan det hända att en läcka bara visar sig när filtret tillämpas i ett verkligt system, där antalet "misstänkta" kan vara enormt och tiden för felsökning begränsad.

Hur visar sig en minnesläcka?

Det är logiskt att anta att i programmets utdata top kommer en ökande procentandel av minnet som används av din applikation att visas.

Det yttre tecknet kommer att vara att systemet vid någon tidpunkt blir långsamt att reagera på musrörelser och långsamt återger skärmen. Det kan också hända att systemlogg ökar, vilket tar upp utrymme på hårddisken. Under tiden kommer din applikation att börja bete sig märkligt, inte svara på kommandon, inte kunna öppna filer osv.

För att identifiera förekomsten av en läcka kommer vi att använda en minnesanalysator (hädanefter analysator). Det kan vara Valgrind (bra artikeln om den) eller inbyggd i kompilatorn gcc MemorySanitizer eller något annat. Om analysatorn visar att läckan inträffar i någon av filtren i grafen, betyder det att det är dags att använda en av metoderna som beskrivs nedan.

Tre pinjeträd-metoden

Som tidigare nämnts, vid minnesläckor kommer analysatorn att peka ut filtret som begärde minnesallokering från heapen. Men den kommer inte att peka ut filtret som "glömde" att återlämna det, vilket faktiskt är den skyldige. På så sätt kan analysatorn bara bekräfta våra farhågor, men inte ange deras rot.

För att ta reda på platsen för det "otäcka" filtret i grafen kan man gå vägen att minska grafen till minsta antalet noder där analysatorn fortfarande upptäcker läckan och i de kvarvarande tre pinjeträden lokalisera det problematiska filtret.

Men det kan hända att om du minskar antalet filter i grafen bryter du den vanliga interaktionen mellan filtren och andra element i ditt system och läckan slutar att manifesteras. I detta fall måste du arbeta med den fullständiga grafen och använda tillvägagångssättet som beskrivs nedan.

Glidande isolator-metoden

För enkelhetens skull kommer vi att använda en graf som består av en kedja av filter. Den är avbildad i bilden.

En vanlig graf där, tillsammans med de färdiga filtren för medieströmmen, tillämpas fyra hantverksfilter F1…F4 av fyra olika typer som du skapade för länge sedan och vars korrekthet du inte tvivlar på. Anta ändå att det finns minnesläckor i några av dem. När vi kör vårt övervakningsprogram med analyzatorn får vi veta från dess rapport att ett visst filter har begärt en viss mängd minne och inte återlämnat det till högen ett visst antal gånger. Det är lätt att gissa att det kommer att hänvisas till interna funktioner för filtertypen MS_VOID_SOURCE. Dess uppgift är att hämta minne från högen. Andra filter bör återlämna det dit. Det vill säga, vi upptäcker ett faktum om en läcka.

För att fastställa var på enheten av transportbandet som inaktiviteten inträffade och ledde till minnesläckan, föreslås det att införa ett extra filter som helt enkelt överför meddelanden från ingången till utgången, men skapar en tung kopia av ingångsmeddelandet och tar bort meddelandet som kom till ingången. Vi kommer att kalla detta filter isolator. Vi antar att eftersom filtret är enkelt så är läckan utesluten i det. En annan positiv egenskap är att om vi lägger till det i vilket som helst avsnitt av vår graf, så påverkar det inte schemat. Vi kommer att avbilda isolatorfiltret som en cirkel med dubbel kontur.

Vi aktiverar isolatorn direkt efter filtret voidsource:

Vi kör programmet igen med analyzatorn och ser att den här gången lägger analysatorn skulden på isolatorn. För det är det nu som skapar datablokkar som sedan går förlorade av en okänd slarvig filter (eller filter). Nästa steg är att flytta isolatorn en position till höger i kedjan, en filter, och köra analysen igen. Så, steg för steg, genom att flytta isolatorn till höger, kommer vi att få en situation där antalet "läckta" minnesblock i den kommande rapporten från analyzatorn minskar. Det betyder att vid det här steget befann sig isolatorn just efter det problematiska filtret. Om det "dåliga" filtret var det enda, försvinner läckan helt. På så sätt har vi lokaliserat det problematiska filtret (eller en av flera). "Genom att laga" filtret kan vi fortsätta att flytta isolatorn till höger i kedjan tills vi helt har besegrat minnesläckorna.

Implementering av isolatorfiltret

Implementeringen av isolatorn ser ut som en vanlig filter. Rubrikfil:

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

Själva filtret:

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

Metod för att ersätta minneshanteringsfunktioner

För mer detaljerade undersökningar finns det en funktion i mediastreamern för att ersätta minnesåtkomstfunktioner med egna, som förutom det primära arbetet också registrerar "Vem, vart och varför". Tre funktioner ersätts. Det görs på följande sätt:

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

Denna möjlighet är värdefull när analysatorn saktar ner filterens arbete så mycket att det påverkar systemets funktioner som vår schema är integrerad i. I en sådan situation måste man avstå från analysatorn och använda ersättningsfunktioner för minneshantering.

Vi har gått igenom handlingsalgoritmen för en enkel graf utan förgreningar. Men denna metod kan också tillämpas på andra situationer, självklart med mer komplexitet, men idén kommer att förbli densamma.

I nästa artikel kommer vi att titta på hur man bedömer belastningen på tickern och hur man hanterar överdriven beräkningsbelastning i mediastreamern.

Källa: habr.com