Mediastreamer2 VoIP ძრავის შესწავლა. ნაწილი 12

სტატიის მასალა აღებულია ჩემი ზენ არხი.

Ბოლოს მუხლიმე დავპირდი, რომ განვიხილავ ტიკერის დატვირთვის შეფასების საკითხს და გადაჭარბებულ გამოთვლით დატვირთვასთან გამკლავების გზებს მედია სტრიმერში. მაგრამ მე გადავწყვიტე, რომ უფრო ლოგიკური იქნებოდა მონაცემთა გადაადგილებასთან დაკავშირებული ხელნაკეთი ფილტრების გამართვის საკითხების გაშუქება და მხოლოდ ამის შემდეგ განვიხილო შესრულების ოპტიმიზაციის საკითხები.

ხელნაკეთი ფილტრების გამართვა

მას შემდეგ, რაც წინა სტატიაში გამოვიკვლიეთ მონაცემთა გადაადგილების მექანიზმი მედიასტრიმერში, ლოგიკური იქნებოდა ვისაუბროთ მასში დაფარულ საფრთხეებზე. „მონაცემთა ნაკადის“ პრინციპის ერთ-ერთი მახასიათებელია ის, რომ გროვიდან მეხსიერების განაწილება ხდება მონაცემთა ნაკადის წყაროებში მდებარე ფილტრებში, ხოლო ნაკადის ბილიკის ბოლოს მდებარე ფილტრები უკვე ანაწილებენ მეხსიერებას დაბრუნებით. გროვამდე. გარდა ამისა, ახალი მონაცემების შექმნა და მათი განადგურება შეიძლება მოხდეს სადღაც შუალედურ წერტილებში. ზოგადად, მეხსიერების გათავისუფლება ხორციელდება ფილტრით, გარდა იმისა, რომელიც შექმნა მონაცემთა ბლოკი.

მეხსიერების გამჭვირვალე მონიტორინგის თვალსაზრისით, გონივრული იქნება, რომ ფილტრმა, შეყვანის ბლოკის მიღებისას, დაუყოვნებლივ გაანადგუროს იგი დამუშავების, მეხსიერების განთავისუფლების შემდეგ და გამომავალი მონაცემებით ახლად შექმნილი ბლოკი დააყენოს გამოსავალზე. ამ შემთხვევაში, ფილტრში მეხსიერების გაჟონვა შეიძლება ადვილად მიკვლეული იყოს - თუ ანალიზატორმა აღმოაჩინა გაჟონვა ფილტრში, მაშინ მას შემდეგ ფილტრი სათანადოდ არ ანადგურებს შემომავალ ბლოკებს და მასში არის შეცდომა. მაგრამ მაღალი წარმადობის შენარჩუნების თვალსაზრისით, მონაცემთა ბლოკებთან მუშაობის ეს მიდგომა არ არის პროდუქტიული - ეს იწვევს ოპერაციების დიდ რაოდენობას მონაცემთა ბლოკებისთვის მეხსიერების გამოყოფის / თავისუფალი გამონაბოლქვის გარეშე.

ამ მიზეზით, მედია ნაკადის ფილტრები, რათა არ შეანელონ მონაცემთა დამუშავება, შეტყობინებების კოპირებისას იყენებენ ფუნქციებს, რომლებიც ქმნიან მსუბუქ ასლებს (მათზე ვისაუბრეთ წინა სტატიაში). ეს ფუნქციები ქმნიან მხოლოდ შეტყობინების სათაურის ახალ ასლს კოპირებული „ძველი“ გზავნილიდან მონაცემთა ბლოკის „მიმაგრებით“ მასზე. შედეგად, ორი სათაური მიმაგრებულია მონაცემთა ერთ ბლოკზე და მონაცემთა ბლოკში მითითების მრიცხველი იზრდება. მაგრამ ეს ორ შეტყობინებას ჰგავს. შეიძლება იყოს მეტი შეტყობინება ასეთი „საჯარო“ მონაცემთა ბლოკით, მაგალითად, MS_TEE ფილტრი ერთდროულად წარმოქმნის ათ ასეთ ნათელ ასლს და ანაწილებს მათ მის გამოსავალს შორის. თუ ჯაჭვში ყველა ფილტრი მუშაობს გამართულად, მილსადენის ბოლოსთვის ეს მითითების რაოდენობა უნდა მიაღწიოს ნულს და მეხსიერების განაწილების ფუნქცია გამოიძახება: ms_free(). თუ ზარი არ მოხდა, მაშინ მეხსიერების ეს ნაწილი აღარ დაბრუნდება გროვაში, ე.ი. ის "ჟონავს". მსუბუქი ასლების გამოყენების ღირებულება არის იოლად განსაზღვრის უნარის დაკარგვა (როგორც ეს იქნებოდა ჩვეულებრივი ასლების გამოყენების შემთხვევაში), რომელ გრაფიკულ ფილტრში ჟონავს მეხსიერება.

ვინაიდან პასუხისმგებლობა მეხსიერების გაჟონვის პოვნაზე "მშობლიურ" ფილტრებში ეკისრება მედია სტრიმერის დეველოპერებს, მაშინ, სავარაუდოდ, თქვენ არ მოგიწევთ მათი გამართვა. მაგრამ თქვენი ხელნაკეთი ფილტრით, თქვენ თავად ხართ თქვენი ბედნიერების მაყვალი და დრო, რომელსაც დახარჯავთ თქვენს კოდში გაჟონვის ძიებაში, თქვენს სიზუსტეზე იქნება დამოკიდებული. თქვენი გამართვის დროის შესამცირებლად, ფილტრების დიზაინის დროს უნდა გავითვალისწინოთ გაჟონვის ლოკალიზაციის ტექნიკა. გარდა ამისა, შეიძლება მოხდეს, რომ გაჟონვა გამოვლინდეს მხოლოდ ფილტრის რეალურ სისტემაში გამოყენებისას, სადაც "ეჭვმიტანილთა" რაოდენობა შეიძლება იყოს უზარმაზარი, ხოლო გამართვის დრო შეზღუდულია.

როგორ ვლინდება მეხსიერების გაჟონვა?

ლოგიკურია ვივარაუდოთ, რომ პროგრამის გამოსავალში დაბრუნება აჩვენებს თქვენი აპლიკაციის მიერ დაკავებული მეხსიერების მზარდ პროცენტს.

გარე მანიფესტაცია შედგება იმაში, რომ რაღაც მომენტში სისტემა ნელა რეაგირებს მაუსის მოძრაობაზე, ნელა გადახაზავს ეკრანს. ასევე შესაძლებელია, რომ სისტემის ჟურნალი გაიზარდოს, რაც მყარ დისკზე ადგილს შეჭამს. ამ შემთხვევაში, თქვენი აპლიკაცია დაიწყებს უცნაურად ქცევას, არ პასუხობს ბრძანებებს, ვერ ხსნის ფაილს და ა.შ.

გაჟონვის ფაქტის დასადგენად გამოვიყენებთ მეხსიერების ანალიზატორს (შემდგომში ანალიზატორი). Ეს შეიძლება იყოს ვალგრინდი (კარგი სტატიის ამის შესახებ) ან ჩაშენებული კომპილატორში gcc მეხსიერების გამაჯანსაღებელი ან კიდევ სხვა რაღაც. თუ ანალიზატორი აჩვენებს, რომ გაჟონვა ხდება გრაფიკის ერთ-ერთ ფილტრში, მაშინ ეს ნიშნავს, რომ დროა გამოიყენოთ ქვემოთ აღწერილი ერთ-ერთი მეთოდი.

სამი ფიჭვის მეთოდი

როგორც ზემოთ აღინიშნა, მეხსიერების გაჟონვის შემთხვევაში, ანალიზატორი მიუთითებს ფილტრზე, რომელმაც მოითხოვა მეხსიერების გამოყოფა გროვიდან. მაგრამ ეს არ მიუთითებს ფილტრზე, რომელმაც "დაავიწყდა" მისი დაბრუნება, რაც, ფაქტობრივად, დამნაშავეა. ამრიგად, ანალიზატორს შეუძლია მხოლოდ დაადასტუროს ჩვენი შიში, მაგრამ არ მიუთითოს მათ ფესვზე.

გრაფაში „ცუდი“ ფილტრის ადგილმდებარეობის გასარკვევად, შეგიძლიათ გადახვიდეთ გრაფიკის შემცირებით კვანძების მინიმალურ რაოდენობამდე, რომლებშიც ანალიზატორი მაინც აღმოაჩენს გაჟონვას და პრობლემური ფილტრის პოვნა დანარჩენ სამ ფიჭვში.

მაგრამ შეიძლება მოხდეს, რომ სვეტში ფილტრების რაოდენობის შემცირებით თქვენ დაარღვიოთ ფილტრებსა და თქვენი სისტემის სხვა ელემენტებს შორის ურთიერთქმედების ნორმალური კურსი და გაჟონვა აღარ გამოჩნდება. ამ შემთხვევაში, თქვენ მოგიწევთ მუშაობა სრული ზომის გრაფიკით და გამოიყენოთ ქვემოთ აღწერილი მიდგომა.

მოცურების იზოლატორის მეთოდი

პრეზენტაციის სიმარტივისთვის, ჩვენ გამოვიყენებთ გრაფიკს, რომელიც შედგება ფილტრების ერთი ჯაჭვისგან. იგი ნაჩვენებია სურათზე.

ჩვეულებრივი გრაფიკი, რომელშიც მზა მედია სტრიმერის ფილტრებთან ერთად გამოყენებულია ოთხი ხელნაკეთი ფილტრი F1…F4, ოთხი განსხვავებული ტიპი, რომლებიც დიდი ხნის წინ გააკეთეთ და მათ სისწორეში ეჭვი არ გეპარებათ. თუმცა, დავუშვათ, რომ რამდენიმე მათგანს აქვს მეხსიერების გაჟონვა. ჩვენი ანალიზატორის ზედამხედველობის პროგრამის გაშვებისას, მისი მოხსენებიდან ვიგებთ, რომ გარკვეულმა ფილტრმა მოითხოვა გარკვეული რაოდენობის მეხსიერება და არ დააბრუნა იგი გროვაში N-ჯერ. ადვილი მისახვედრია, რომ იქნება მითითება MS_VOID_SOURCE ტიპის შიდა ფილტრის ფუნქციებზე. მისი ამოცანაა გროვიდან მეხსიერების აღება. სხვა ფილტრებმა უნდა დააბრუნონ იქ. იმათ. ჩვენ ვიპოვით გაჟონვას.

იმის დასადგენად, თუ რომელ მონაკვეთზე მოხდა მილსადენის უმოქმედობა, რამაც გამოიწვია მეხსიერების გაჟონვა, შემოთავაზებულია დამატებითი ფილტრის შემოღება, რომელიც უბრალოდ გადააქვს შეტყობინებებს შეყვანიდან გამოსავალზე, მაგრამ ამავე დროს ქმნის არამსუბუქ, ნორმალურს. შეყვანის შეტყობინების "მძიმე" ასლი, შემდეგ კი გამომავალზე მისული შეტყობინების მთლიანად წაშლა. ასეთ ფილტრს იზოლატორს დავარქმევთ. ჩვენ გვჯერა, რომ რადგან ფილტრი მარტივია, მასში გაჟონვა გამორიცხულია. და კიდევ ერთი დადებითი თვისება - თუ მას დავამატებთ ჩვენს გრაფიკის ნებისმიერ ადგილს, მაშინ ეს არანაირად არ იმოქმედებს მიკროსქემის მუშაობაზე. ჩვენ გამოვსახავთ იზოლატორის ფილტრს წრედ ორმაგი კონტურით.

ჩართეთ იზოლატორი უშუალოდ voidsourse ფილტრის შემდეგ:

პროგრამას ისევ ანალიზატორით ვუშვებთ და ვხედავთ, რომ ამჯერად ანალიზატორი იზოლატორს დაადანაშაულებს. ყოველივე ამის შემდეგ, ის არის ის, ვინც ახლა ქმნის მონაცემთა ბლოკებს, რომლებიც შემდეგ იკარგება უცნობი დაუდევრობითი ფილტრით (ან ფილტრებით). შემდეგი ნაბიჯი არის ჯაჭვის გასწვრივ იზოლატორის გადატანა მარჯვნივ, ერთი ფილტრით და ანალიზის თავიდან დაწყება. ასე რომ, ეტაპობრივად, იზოლატორის მარჯვნივ გადაადგილებით, ვიღებთ სიტუაციას, როდესაც ანალიზატორის შემდეგ მოხსენებაში "გაჟონილი" მეხსიერების ბლოკების რაოდენობა მცირდება. ეს ნიშნავს, რომ ამ საფეხურზე იზოლატორი პრობლემური ფილტრის შემდეგ დაუყოვნებლივ ხვდებოდა ჯაჭვში. თუ მხოლოდ ერთი "ცუდი" ფილტრი იყო, მაშინ გაჟონვა საერთოდ გაქრება. ამრიგად, ჩვენ მოვახდინეთ პრობლემური ფილტრის ლოკალიზება (ან რამდენიმედან ერთ-ერთი). ფილტრის „დაფიქსირების“ შემდეგ, ჩვენ შეგვიძლია გავაგრძელოთ იზოლატორის გადატანა მარჯვნივ ჯაჭვის გასწვრივ, სანამ მეხსიერების გაჟონვა მთლიანად არ აღმოიფხვრება.

იზოლატორის ფილტრის დანერგვა

იზოლატორის დანერგვა ჩვეულებრივ ფილტრს ჰგავს. სათაურის ფაილი:

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