VoIP motor Mediastreamer2 tanulmányozása. 12. rész

A cikk anyaga az én Dzen csatornámból származik.

A múltban a Spotify döntéshozatali módszertanáról. Egyre több felhasználó preferálja a zenehallgatást mobilon a streaming szolgáltatásban, de a cégnél túlnyomórészt webprogramozók dolgoznak. A Spotify elemezte ezt a helyzetet, és úgy döntött, hogy több mobilfejlesztőt vesz fel, valamint átnevezi a webes szakembereket új irányba:, megígértem, hogy foglalkozom a terhelésértékelés kérdésével a ticker esetében, és a túlzott számítási terhelés kezelésének módjaival a médiastreamerben. De úgy döntöttem, logikusabb lesz először a kraft szűrők hibakeresési kérdéseit bemutatni, amelyek az adatok áthelyezésével kapcsolatosak, és csak ezt követően foglalkozni a teljesítményoptimalizálás kérdéseivel.

A kraft szűrők hibakeresése

Miután a korábbi cikkben áttekintettük az adatok áthelyezésének mechanizmusát a médiastreamerben, logikus lenne beszélni az abban rejlő veszélyekről. Az "adata áramlása" elv egyik sajátossága, hogy a memória kiemelése a halomból azokban a szűrőkben történik, amelyek az adatfolyam kezdetén helyezkednek el, míg a memória felszabadítása, vissza a halomba, már a folyamat végén található szűrők által történik. Ezen kívül az új adatok létrehozása és megsemmisítése valahol a köztes pontokban is előfordulhat. Általános esetben a memória felszabadítását nem az a szűrő végzi, amelyik létrehozta az adatblokkot.

A memória átlátható nyomon követése szempontjából ésszerű lenne, ha a szűrő, miután megkapta a bemeneti blokkját, azonnal megsemmisítené azt a feldolgozás után a memória felszabadításával, és a kimeneten egy újonnan létrehozott blokkot helyezne el a kimeneti adatokkal. Ebben az esetben a memória szivárgása a szűrőben könnyen nyomon követhető lenne — ha az elemző szivárgást észlel a szűrőben, akkor a következő szűrő nem semmisíti meg megfelelően a bejövő blokkokat, ami hiba lenne benne. De a magas teljesítmény fenntartása szempontjából ez a megközelítés a dolgokkal való munkára nem produktív — ez nagyszámú művelethez vezet a memória kiemelésére/felszabadítására az adatblokkok számára, bármilyen hasznos kimenet nélkül.

Ezért a médiastreamer szűrők, hogy ne lassítsák az adatok feldolgozását, üzenetek másolásakor olyan funkciókat használnak, amelyek könnyű másolatokat hoznak létre (erről az előző cikkünkben írtunk). Ezek a funkciók csak új üzenetfejléc példányt hoznak létre, "rögzítve" hozzá a másolt "régi" üzenet adatblokkot. Ennek eredményeként egy adatblokkhoz két fejléc kapcsolódik, és a hivatkozási számláló az adatblokkban növekszik. De ez úgy fog kinézni, mint két üzenet. Az ilyen "megosztott" adatblokkal rendelkező üzenetek száma lehet több is, például az MS_TEE szűrő egyszerre több ilyen könnyű másolatot generál, amelyeket a kimenetei között oszt el. Minden szűrő megfelelő működése mellett a cső végén ennek a hivatkozási számlálónak nullára kell csökkennie, amelyet a memóriafelszabadító funkció hív meg: ms_free(). Ha a hívás nem történik meg, akkor ez a memória már nem térhet vissza a halomba, azaz "szivárogni" fog. A könnyű másolatok használatának ára az a lehetőség elvesztése, hogy könnyen megállapítsuk (ahogy az normál másolatokkal lett volna), hogy mely szűrő grafikonban szivárog a memória.

Mivel a memória szivárgások keresésének felelőssége a "natív" szűrőkben a médiastreamer fejlesztőinél van, valószínűleg nem kell őket hibakeresni. De a saját készítésű szűrőddel – te vagy a saját boldogságod kovácsa, és a te precizitásodtól függ, mennyi időt töltesz el a hibák keresésével a kódodban. Az időd letartóztatásának csökkentése érdekében meg kell vizsgálnunk a memória szivárgások lokalizálásának módszereit a szűrők fejlesztésekor. Ezenkívül előfordulhat, hogy a szivárgás csak akkor nyilvánul meg, amikor a szűrőt egy valós rendszerben alkalmazzák, ahol a "gyanúsítottak" száma hatalmas lehet, és a hibakeresésre szánt idő korlátozott.

Hogyan mutatkozik meg a memória szivárgás?

Logikus feltételezni, hogy a program kimenetében top a memória folyamatosan növekvő százaléka fog megjelenni, amelyet az alkalmazásod foglal el.

A külső megnyilvánulás abban áll majd, hogy a rendszer egy idő után lassan reagál a mouse mozgására, lassan frissíti a képernyőt. Előfordulhat, hogy a rendszer naplója is nőni fog, ezzel helyet foglalva a merevlemezen. Eközben az alkalmazásod furcsa módon fog viselkedni, nem reagál a parancsokra, nem tud fájlt megnyitni, stb.

A szivárgás megállapításához memóriaelemzőt (a továbbiakban: elemző) fogunk használni. Ez lehet Valgrind (jó cikk erről) vagy a fordítóba beépített gcc MemorySanitizer vagy valami más. Ha az elemző azt mutatja, hogy a szivárgás egy grafikon egyik szűrőjében történik, az azt jelenti, hogy itt az ideje alkalmazni az alább leírt módszerek egyikét.

A három szűrő módszere

Ahogy korábban említve lett, szivárgás esetén az elemző arra a szűrőre mutat, amely a memóriát igényelte a halomból. De nem fogja megmutatni azt a szűrőt, amely "elfelejtette" visszaadni, amely valójában a hibás. Így az elemző csak megerősítheti a gyanúnkat, de nem mutatja meg annak gyökerét.

A "rossz" szűrő helyének meghatározásához a grafikon minimalizálásának lehetséges útját követhetjük, hogy a lehető legkisebb csomópontoknál az elemző még mindig észleli a szivárgást, és a megmaradt három szűrőn belül lokalizáljuk a problémás szűrőt.

De előfordulhat, hogy a grafikon szűrőinek számának csökkentésekor megszakítod a szűrők normál kölcsönhatását a rendszered többi elemével, és a szivárgás már nem mutatkozik meg. Ebben az esetben a teljes méretű grafikonon kell dolgozni, és az alább ismertetett megközelítést kell alkalmazni.

A mozgó szigetelő módszere

A magyarázat egyszerűsítése érdekében egy olyan grafikonnal fogunk dolgozni, amely egy szűrőláncból áll. Ez a rajzon látható.

Egy normál gráf, amelyben a médiastreamer kész szűrői mellett négy kézműves szűrő van F1…F4, négy különböző típustól, amelyeket régen készítettél, és biztos vagy a helyességükben. Mindazonáltal feltételezzük, hogy ezek közül néhányban memória szivárgás van. A programunk futtatásával, amely a figyelő elemzőt használja, az abból származó jelentésből megtudjuk, hogy egy bizonyos szűrő kért egy bizonyos mennyiségű memóriát, és azt nem adta vissza a heap-be N darabszor. Könnyen kitalálható, hogy a hivatkozás a MS_VOID_SOURCE típusú szűrő belső funkcióira mutat. Ennek feladata az, hogy memóriát vegyen el a heap-ből. Azt más szűrőknek kell visszaadniuk. Tehát észleljük a szivárgás tényét.

Annak meghatározására, hogy a gyártósor mely szakaszán történt az a tétlenség, amely memória szivárgáshoz vezetett, javasolt egy további szűrőt bevezetni, amely egyszerűen átkonvertálja az üzeneteket a bemenetről a kimenetre, viszont létrehoz egy nem könnyű, hanem normális "nehéz" másolatot a bemeneti üzenetről, majd teljesen eltávolítja a bemenetre érkező üzenetet. Ezt a szűrőt izolátornak nevezzük. Feltételezzük, hogy mivel a szűrő egyszerű, ezért benne a szivárgás kizárt. Egy másik pozitív tulajdonsága pedig, hogy ha bármelyik helyre beillesztjük a gráfunkba, az nem befolyásolja a séma működését. Az izoláló szűrőt dupla kerületű körként ábrázoljuk.

Az izolátort azonnal a voidsource szűrő után kapcsoljuk be:

Újra elindítjuk a programot az elemzővel, és azt látjuk, hogy ez alkalommal az elemző az izolátort okolja. Végül is ő hozza létre azokat az adatblokkot, amelyek később egy ismeretlen gondatlan szűrő (vagy szűrők) által elvesznek. A következő lépésben az izolátort egy szűrővel jobbra mozgatjuk, és újra elindítjuk az elemzést. Tehát, lépésről lépésre jobbra mozgatva az izolátort, olyan helyzetet kapunk, amikor a következő elemző jelentésben az "elhalványult" memória blokkok száma csökken. Ez azt jelenti, hogy ezen a lépésen az izolátor a problémás szűrő után helyezkedett el a láncban. Ha a "rossz" szűrő egyetlen volt, akkor a szivárgás teljesen eltűnik. Így lokalizáltuk a problémás szűrőt (vagy az egyik a több közül). A szűrő "javítása" után folytathatjuk az izolátor jobbra mozgatását a láncon, amíg teljes mértékben meg nem szüntetjük a memória szivárgásokat.

Az izoláló szűrő implementálása

Az izolátor megvalósítása úgy néz ki, mint egy normál szűrő. Fejléc:

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

A szűrő:

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

Memóriakezelő függvények helyettesítési metódus

Finomabb kutatásokhoz a médiastreamer lehetőséget biztosít a memóriához való hozzáférés függvényeinek saját magunk által történő helyettesítésére, amelyek alapvető munkájukon túl rögzítik, hogy "Ki, hova és miért". Három függvény kerül helyettesítésre. Ez a következőképpen történik:

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

Ez a lehetőség hasznos, amikor az elemző annyira lelassítja a szűrők működését, hogy ez zavart okoz a rendszerben, amelybe a sémánk be van építve. Ebben a helyzetben kénytelenek vagyunk lemondani az elemzőről, és a memóriakezelő függvények helyettesítését alkalmazni.

Megvizsgáltuk az eljárások algoritmusát egy egyszerű gráf számára, amely nem tartalmaz ágazásokat. De ezt a megközelítést más esetekre is alkalmazni lehet, persze bonyolultabb formában, de az ötlet ugyanaz marad.

A következő cikkben a ticker terhelésének értékelésével és a médiastreamerben jelentkező túlzott számítási terhelés kezelésének módjaival foglalkozunk.

Forrás: habr.com