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