Mediastreamer2 VoIP એન્જિનની શોધખોળ. ભાગ 12

લેખની સામગ્રી મારા પરથી લેવામાં આવી છે ઝેન ચેનલ.

છેલ્લામાં લેખ, મેં ટીકર પરના લોડનું મૂલ્યાંકન કરવાના મુદ્દા અને મીડિયા સ્ટ્રીમરમાં વધુ પડતા કમ્પ્યુટિંગ લોડનો સામનો કરવાની રીતો પર વિચાર કરવાનું વચન આપ્યું હતું. પરંતુ મેં નક્કી કર્યું છે કે ડેટા ચળવળથી સંબંધિત ક્રાફ્ટ ફિલ્ટર્સના ડિબગીંગના મુદ્દાઓને આવરી લેવા માટે તે વધુ તાર્કિક હશે અને માત્ર ત્યારે જ પ્રદર્શન ઑપ્ટિમાઇઝેશનના મુદ્દાઓ પર વિચાર કરો.

ડીબગીંગ ક્રાફ્ટ ફિલ્ટર્સ

અમે અગાઉના લેખમાં મીડિયા સ્ટ્રીમરમાં ડેટા ખસેડવાની પદ્ધતિને જોયા પછી, તેમાં છુપાયેલા જોખમો વિશે વાત કરવી તાર્કિક રહેશે. "ડેટા ફ્લો" સિદ્ધાંતની એક વિશેષતા એ છે કે ડેટા ફ્લોના સ્ત્રોત પર સ્થિત ફિલ્ટર્સના ઢગલામાંથી મેમરીની ફાળવણી કરવામાં આવે છે, અને મેમરીને મુક્ત કરવામાં આવે છે અને પ્રવાહના અંતે સ્થિત ફિલ્ટર્સ દ્વારા ઢગલામાં પરત કરવામાં આવે છે. માર્ગ વધુમાં, નવા ડેટાનું નિર્માણ અને તેનો વિનાશ વચ્ચે ક્યાંક થઈ શકે છે. સામાન્ય રીતે, મેમરી રીલીઝ ડેટા બ્લોક બનાવનાર કરતાં અલગ ફિલ્ટર દ્વારા કરવામાં આવે છે.

પારદર્શક મેમરી મોનિટરિંગના દૃષ્ટિકોણથી, ફિલ્ટર માટે, ઇનપુટ બ્લોક પ્રાપ્ત થવા પર, પ્રક્રિયા કર્યા પછી તરત જ તેનો નાશ કરવા, મેમરીને મુક્ત કરવા અને આઉટપુટ ડેટા સાથે નવા બનાવેલા બ્લોકને આઉટપુટ કરવા માટે તે વાજબી રહેશે. આ કિસ્સામાં, ફિલ્ટરમાં મેમરી લીક સરળતાથી શોધી શકાય છે - જો વિશ્લેષક ફિલ્ટરમાં લીક શોધે છે, તો પછીનું ફિલ્ટર ઇનકમિંગ બ્લોક્સને યોગ્ય રીતે નષ્ટ કરતું નથી અને તેમાં ભૂલ છે. પરંતુ ઉચ્ચ પ્રદર્શન જાળવવાના દૃષ્ટિકોણથી, ડેટા બ્લોક્સ સાથે કામ કરવાનો આ અભિગમ ફળદાયી નથી - તે કોઈપણ ઉપયોગી આઉટપુટ વિના ડેટા બ્લોક્સ માટે/મુક્ત મેમરી ફાળવવા માટે મોટી સંખ્યામાં કામગીરી તરફ દોરી જાય છે.

આ કારણોસર, મીડિયા સ્ટ્રીમર ફિલ્ટર્સ, ડેટા પ્રોસેસિંગને ધીમું ન કરવા માટે, ફંક્શનનો ઉપયોગ કરે છે જે સંદેશાઓની નકલ કરતી વખતે સરળ નકલો બનાવે છે (અમે તેના વિશે અગાઉના લેખમાં વાત કરી હતી). આ ફંક્શન્સ ફક્ત કોપી કરવામાં આવતા "જૂના" મેસેજમાંથી ડેટાના બ્લોકને "જોડવા" દ્વારા મેસેજ હેડરનો નવો દાખલો બનાવે છે. પરિણામે, એક ડેટા બ્લોક સાથે બે હેડરો જોડાયેલા છે અને ડેટા બ્લોકમાં રેફરન્સ કાઉન્ટર વધ્યું છે. પરંતુ તે બે સંદેશા જેવો દેખાશે. આવા "સામાજિક" ડેટા બ્લોક સાથે વધુ સંદેશા હોઈ શકે છે, ઉદાહરણ તરીકે, MS_TEE ફિલ્ટર એક જ સમયે આવી એક ડઝન પ્રકાશ નકલો બનાવે છે, તેને તેના આઉટપુટમાં વિતરિત કરે છે. જો સાંકળમાંના તમામ ફિલ્ટર્સ યોગ્ય રીતે કાર્ય કરે છે, તો પાઇપલાઇનના અંત સુધીમાં આ સંદર્ભ કાઉન્ટર શૂન્ય સુધી પહોંચવું જોઈએ અને મેમરી રિલીઝ ફંક્શનને કહેવામાં આવશે: ms_free(). જો કૉલ ન થાય, તો પછી મેમરીનો આ ભાગ હવે ઢગલામાં પાછો આવશે નહીં, એટલે કે. તે "લીક" કરશે. લાઇટ કોપીનો ઉપયોગ કરવાની કિંમત એ સરળતાથી નક્કી કરવાની ક્ષમતા ગુમાવવી છે (જેમ કે નિયમિત નકલો સાથે કેસ હશે) જે ગ્રાફ ફિલ્ટર મેમરી લીક કરી રહ્યું છે.

મીડિયા સ્ટ્રીમર ડેવલપર્સ મૂળ ફિલ્ટર્સમાં મેમરી લિક શોધવા માટે જવાબદાર હોવાથી, તમારે મોટે ભાગે તેમને ડીબગ કરવાની જરૂર નથી. પરંતુ તમારા ક્રાફ્ટ ફિલ્ટર સાથે, તમે તમારી પોતાની ખુશીના ખડમાકડી છો, અને તમે તમારા કોડમાં લીક શોધવામાં કેટલો સમય પસાર કરશો તે તમારી ચોકસાઈ પર નિર્ભર રહેશે. તમારા ડિબગીંગ સમયને ઘટાડવા માટે, ફિલ્ટર્સ વિકસાવતી વખતે અમારે લીક શોધ તકનીકો જોવાની જરૂર છે. આ ઉપરાંત, એવું બની શકે છે કે જ્યારે વાસ્તવિક સિસ્ટમમાં ફિલ્ટર લાગુ કરવામાં આવે ત્યારે જ લીક પોતાને પ્રગટ કરશે, જ્યાં "શંકાસ્પદ" ની સંખ્યા મોટી હોઈ શકે છે અને ડીબગિંગ માટેનો સમય મર્યાદિત હોઈ શકે છે.

મેમરી લીક કેવી રીતે પ્રગટ થાય છે?

પ્રોગ્રામ આઉટપુટમાં તે ધારવું તાર્કિક છે ટોચ તમારી એપ્લિકેશન દ્વારા કબજે કરેલી મેમરીની વધતી જતી ટકાવારી બતાવશે.

બાહ્ય અભિવ્યક્તિ એ હશે કે અમુક સમયે સિસ્ટમ માઉસની હિલચાલને ધીમેથી પ્રતિસાદ આપવાનું શરૂ કરશે અને ધીમે ધીમે સ્ક્રીનને ફરીથી દોરશે. તે પણ શક્ય છે કે સિસ્ટમ લોગ વધશે, તમારી હાર્ડ ડ્રાઈવ પર જગ્યા ખાશે. આ કિસ્સામાં, તમારી એપ્લિકેશન વિચિત્ર રીતે વર્તવાનું શરૂ કરશે, આદેશોનો જવાબ આપશે નહીં, ફાઇલ ખોલી શકશે નહીં, વગેરે.

લીકની ઘટનાને શોધવા માટે, અમે મેમરી વિશ્લેષક (ત્યારબાદ વિશ્લેષક તરીકે ઓળખાય છે) નો ઉપયોગ કરીશું. તે હોઈ શકે છે વેલગ્રિંડ (સારું લેખ તેના વિશે) અથવા કમ્પાઇલરમાં બિલ્ટ જીસીસી મેમરી સેનિટાઈઝર અથવા બીજું કંઈપણ. જો વિશ્લેષક બતાવે છે કે ગ્રાફ ફિલ્ટર્સમાંથી એકમાં લીક થાય છે, તો આનો અર્થ એ છે કે નીચે વર્ણવેલ પદ્ધતિઓમાંથી એકને લાગુ કરવાનો સમય છે.

ત્રણ પાઇન્સ પદ્ધતિ

ઉપર જણાવ્યા મુજબ, જો મેમરી લીક હોય, તો વિશ્લેષક ફિલ્ટર તરફ નિર્દેશ કરશે જેણે ઢગલામાંથી મેમરી ફાળવણીની વિનંતી કરી હતી. પરંતુ તે ફિલ્ટરને નિર્દેશ કરશે નહીં કે જે તેને પરત કરવાનું "ભૂલી ગયું" છે, જે હકીકતમાં, ગુનેગાર છે. આમ, વિશ્લેષક ફક્ત આપણા ભયની પુષ્ટિ કરી શકે છે, પરંતુ તેના મૂળને સૂચવતું નથી.

ગ્રાફમાં "ખરાબ" ફિલ્ટરનું સ્થાન શોધવા માટે, તમે ગ્રાફને ન્યૂનતમ સંખ્યામાં નોડ્સ સુધી ઘટાડી શકો છો કે જેના પર વિશ્લેષક હજી પણ લીક શોધે છે અને બાકીના ત્રણ પાઈનમાં સમસ્યારૂપ ફિલ્ટરને સ્થાનીકૃત કરી શકે છે.

પરંતુ એવું બની શકે છે કે ગ્રાફમાં ફિલ્ટર્સની સંખ્યા ઘટાડીને, તમે ફિલ્ટર્સ અને તમારી સિસ્ટમના અન્ય ઘટકો વચ્ચેની ક્રિયાપ્રતિક્રિયાના સામાન્ય માર્ગને વિક્ષેપિત કરશો અને લીક હવે દેખાશે નહીં. આ કિસ્સામાં, તમારે પૂર્ણ-કદના ગ્રાફ સાથે કામ કરવું પડશે અને નીચે દર્શાવેલ અભિગમનો ઉપયોગ કરવો પડશે.

સ્લાઇડિંગ ઇન્સ્યુલેટર પદ્ધતિ

પ્રસ્તુતિની સરળતા માટે, અમે એક ગ્રાફનો ઉપયોગ કરીશું જેમાં ફિલ્ટર્સની એક સાંકળ છે. તેણી ચિત્રમાં બતાવવામાં આવી છે.

એક નિયમિત આલેખ જેમાં, તૈયાર મીડિયા સ્ટ્રીમર ફિલ્ટર્સ સાથે, ચાર ક્રાફ્ટ ફિલ્ટર્સ F1...F4 નો ઉપયોગ કરવામાં આવે છે, ચાર અલગ-અલગ પ્રકારના, જે તમે લાંબા સમય પહેલા બનાવ્યા હતા અને તેમની સાચીતા વિશે કોઈ શંકા નથી. જો કે, ચાલો માની લઈએ કે તેમાંના ઘણામાં મેમરી લીક છે. વિશ્લેષકને મોનિટર કરવા માટે અમારો પ્રોગ્રામ ચલાવતા, અમે તેના અહેવાલમાંથી શીખીએ છીએ કે ચોક્કસ ફિલ્ટરે ચોક્કસ માત્રામાં મેમરીની વિનંતી કરી હતી અને તેને ઢગલા N નંબર પર પાછી આપી નથી. તમે સરળતાથી અનુમાન કરી શકો છો કે MS_VOID_SOURCE પ્રકારના આંતરિક ફિલ્ટર કાર્યોની લિંક હશે. તેનું કાર્ય ઢગલામાંથી મેમરી લેવાનું છે. અન્ય ફિલ્ટર્સે તેને ત્યાં પરત કરવું આવશ્યક છે. તે. અમે લીકની હકીકત શોધીશું.

મેમરી લીક તરફ દોરી જતા પાઇપલાઇનના કયા વિભાગમાં નિષ્ક્રિયતા હતી તે નિર્ધારિત કરવા માટે, એક વધારાનું ફિલ્ટર રજૂ કરવાની દરખાસ્ત કરવામાં આવી છે જે ફક્ત સંદેશાને ઇનપુટથી આઉટપુટમાં સ્થાનાંતરિત કરે છે, પરંતુ તે જ સમયે ઇનપુટ સંદેશની નકલ બનાવે છે જે પ્રકાશ નથી. , પરંતુ તેના બદલે સામાન્ય "ભારે" એક, પછી પ્રવેશદ્વાર પર પ્રાપ્ત સંદેશને સંપૂર્ણપણે કાઢી નાખે છે. અમે આવા ફિલ્ટરને ઇન્સ્યુલેટર કહીશું. અમે માનીએ છીએ કે ફિલ્ટર સરળ હોવાથી, તેમાં કોઈ લીકેજ નથી. અને એક વધુ સકારાત્મક ગુણધર્મ - જો આપણે તેને આપણા ગ્રાફમાં ગમે ત્યાં ઉમેરીએ, તો આ સર્કિટના સંચાલનને કોઈપણ રીતે અસર કરશે નહીં. અમે ફિલ્ટર-આઇસોલેટરને ડબલ સર્કિટ સાથે વર્તુળના સ્વરૂપમાં દર્શાવીશું.

અમે વોઇડસોર્સ ફિલ્ટર પછી તરત જ આઇસોલેટરને ચાલુ કરીએ છીએ:

અમે ફરીથી વિશ્લેષક સાથે પ્રોગ્રામ ચલાવીએ છીએ, અને આપણે જોઈએ છીએ કે આ વખતે વિશ્લેષક ઇન્સ્યુલેટરને દોષ આપશે. છેવટે, તે તે છે જે હવે ડેટાના બ્લોક્સ બનાવે છે, જે પછી અજાણ્યા બેદરકાર ફિલ્ટર (અથવા ફિલ્ટર્સ) દ્વારા ખોવાઈ જાય છે. આગળનું પગલું એ છે કે ઇન્સ્યુલેટરને સાંકળની સાથે જમણી બાજુએ, એક ફિલ્ટર દ્વારા ખસેડો અને ફરીથી વિશ્લેષણ શરૂ કરો. તેથી, આઇસોલેટરને જમણી તરફ ખસેડવાથી, અમને એક એવી પરિસ્થિતિ મળશે જ્યાં આગામી વિશ્લેષક રિપોર્ટમાં "લીક" મેમરી બ્લોક્સની સંખ્યા ઘટશે. આનો અર્થ એ છે કે આ પગલા પર ઇન્સ્યુલેટર સમસ્યા ફિલ્ટર પછી તરત જ સાંકળમાં હતું. જો ત્યાં ફક્ત એક "ખરાબ" ફિલ્ટર હતું, તો પછી લીક સંપૂર્ણપણે અદૃશ્ય થઈ જશે. આમ, અમે સમસ્યારૂપ ફિલ્ટર (અથવા અનેકમાંથી એક) સ્થાનિકીકરણ કર્યું. ફિલ્ટરને "નિશ્ચિત" કર્યા પછી, અમે મેમરી લીકને સંપૂર્ણપણે હરાવી ન લઈએ ત્યાં સુધી અમે સાંકળની સાથે જમણી તરફ આઇસોલેટરને ખસેડવાનું ચાલુ રાખી શકીએ છીએ.

આઇસોલેટર ફિલ્ટરનું અમલીકરણ

આઇસોલેટર અમલીકરણ નિયમિત ફિલ્ટર જેવું જ દેખાય છે. હેડર ફાઇલ:

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

આ લક્ષણ એવા કિસ્સાઓમાં મદદ કરે છે કે જ્યાં વિશ્લેષક ફિલ્ટર્સની કામગીરીને એટલી ધીમી કરે છે કે જે સિસ્ટમમાં આપણું સર્કિટ બનાવવામાં આવ્યું છે તેનું સંચાલન ખોરવાઈ જાય છે. આવી સ્થિતિમાં, તમારે વિશ્લેષકનો ત્યાગ કરવો પડશે અને મેમરી સાથે કામ કરવા માટે ફંક્શન્સના અવેજીનો ઉપયોગ કરવો પડશે.

અમે એક સરળ ગ્રાફ માટે ક્રિયાઓના અલ્ગોરિધમનો વિચાર કર્યો છે જેમાં શાખાઓ નથી. પરંતુ આ અભિગમ અન્ય કિસ્સાઓમાં લાગુ કરી શકાય છે, અલબત્ત વધુ જટિલતા સાથે, પરંતુ વિચાર એ જ રહે છે.

હવે પછીના લેખમાં, અમે ટીકર પરના ભારનો અંદાજ કાઢવાના મુદ્દા અને મીડિયા સ્ટ્રીમરમાં વધુ પડતા કમ્પ્યુટિંગ લોડનો સામનો કરવાની રીતો જોઈશું.

સોર્સ: www.habr.com