Mediastreamer2 VoIP 엔진 탐색. 12 부

글의 소재는 제 글에서 가져왔습니다. 젠 채널.

과거에 기사, 티커 부하 추정 문제와 미디어 스트리머의 과도한 컴퓨팅 부하 처리 방안을 고민하기로 약속했습니다. 그러나 데이터 이동과 관련된 공예 필터 디버깅 문제를 다루고 성능 최적화 문제를 고려하는 것이 더 논리적이라고 결정했습니다.

크래프트 필터 디버깅

이전 기사에서 미디어 스트리머의 데이터 이동 메커니즘을 살펴본 후 여기에 숨겨진 위험에 대해 이야기하는 것이 논리적일 것입니다. "데이터 흐름" 원칙의 특징 중 하나는 힙에서 메모리 할당이 데이터 흐름의 소스에 위치한 필터에서 발생하고 흐름 경로 끝에 위치한 필터가 이미 반환으로 메모리 할당을 해제한다는 것입니다. 힙에. 또한 중간 지점 어딘가에서 새로운 데이터의 생성 및 파괴가 발생할 수 있습니다. 일반적으로 메모리 해제는 데이터 블록을 생성한 필터가 아닌 다른 필터에 의해 수행됩니다.

투명한 메모리 모니터링의 관점에서 필터는 입력 블록을 수신할 때 처리 후 즉시 파괴하고 메모리를 해제하고 출력 데이터가 있는 새로 생성된 블록을 출력에 넣는 것이 합리적입니다. 이 경우 필터의 메모리 누수를 쉽게 추적할 수 있습니다. 분석기가 필터의 누수를 감지하면 뒤따르는 필터가 들어오는 블록을 제대로 파괴하지 않고 오류가 있는 것입니다. 그러나 고성능 유지의 관점에서 볼 때 데이터 블록 작업에 대한 이러한 접근 방식은 생산적이지 않습니다. 유용한 소모 없이 데이터 블록에 대한 메모리를 할당/해제하는 많은 작업으로 이어집니다.

이러한 이유로 미디어 스트리머 필터는 데이터 처리 속도를 늦추지 않기 위해 메시지를 복사할 때 가벼운 복사본을 만드는 기능을 사용합니다(이전 기사에서 이에 대해 이야기했습니다). 이러한 함수는 복사된 "오래된" 메시지의 데이터 블록을 "첨부"하여 메시지 헤더의 새 복사본을 만듭니다. 결과적으로 하나의 데이터 블록에 두 개의 헤더가 첨부되고 데이터 블록의 참조 카운터가 증가합니다. 그러나 두 개의 메시지처럼 보일 것입니다. 이러한 "공개" 데이터 블록이 있는 메시지가 더 있을 수 있습니다. 예를 들어 MS_TEE 필터는 한 번에 XNUMX개의 이러한 라이트 복사본을 생성하여 출력에 배포합니다. 체인의 모든 필터가 올바르게 작동하면 파이프라인의 끝에서 이 참조 횟수가 XNUMX에 도달하고 메모리 할당 해제 함수가 호출됩니다. ms_free(). 호출이 발생하지 않으면 이 메모리 조각은 더 이상 힙으로 반환되지 않습니다. 그는 "누설"합니다. 가벼운 복사본을 사용하는 비용은 (일반 복사본을 사용하는 경우와 마찬가지로) 어떤 그래프 필터에서 메모리가 누출되는지 쉽게 확인할 수 있는 능력의 손실입니다.

"네이티브" 필터에서 메모리 누수를 찾는 책임은 미디어 스트리머 개발자에게 있으므로 디버깅할 필요가 없을 것입니다. 그러나 제작 필터를 사용하면 자신이 행복의 메뚜기이며 코드의 누출을 검색하는 데 소요되는 시간은 정확도에 따라 달라집니다. 디버깅 시간을 줄이려면 필터를 설계할 때 누수 지역화 기술을 살펴봐야 합니다. 또한 "용의자"의 수가 많고 디버깅 시간이 제한되는 실제 시스템에서 필터를 적용할 때만 누출이 나타날 수 있습니다.

메모리 누수는 어떻게 나타납니까?

프로그램의 출력에서 상단 응용 프로그램이 차지하는 메모리의 비율이 증가하는 것을 보여줍니다.

외부 표현은 어느 시점에서 시스템이 마우스의 움직임에 천천히 반응하여 천천히 화면을 다시 그린다는 사실로 구성됩니다. 시스템 로그가 커져서 하드 드라이브의 공간을 차지할 수도 있습니다. 이 경우 응용 프로그램이 명령에 응답하지 않거나 파일을 열 수 없는 등 이상하게 작동하기 시작합니다.

누출 사실을 확인하기 위해 메모리 분석기(이하 분석기라고 함)를 사용합니다. 그것은 수 발그린드 (좋은 기사 그것에 대해) 또는 컴파일러에 내장 GCC 메모리세니타이저 또는 다른 것. 분석기가 그래프 필터 중 하나에서 누출이 발생한 것으로 표시되면 아래 설명된 방법 중 하나를 적용할 때임을 의미합니다.

쓰리 파인즈 방식

위에서 언급했듯이 메모리 누수가 발생하면 분석기는 힙에서 메모리 할당을 요청한 필터를 가리킵니다. 그러나 그것은 그것을 반환하는 것을 "잊은"필터를 가리키지 않을 것입니다. 따라서 분석자는 우리의 두려움을 확인할 수 있을 뿐 그 뿌리를 지적하지는 못합니다.

그래프에서 "불량" 필터의 위치를 ​​찾으려면 분석기가 여전히 누수를 감지하는 최소 노드 수로 그래프를 줄이고 나머지 XNUMX개의 소나무에서 문제가 있는 필터를 찾을 수 있습니다.

그러나 열의 필터 수를 줄이면 필터와 시스템의 다른 요소 간의 정상적인 상호 작용 과정이 중단되고 누출이 더 이상 나타나지 않을 수 있습니다. 이 경우 전체 크기 그래프로 작업하고 아래에 설명된 접근 방식을 사용해야 합니다.

슬라이딩 절연체 방식

간단하게 표시하기 위해 단일 필터 체인으로 구성된 그래프를 사용합니다. 그녀는 그림에 표시됩니다.

기성품 미디어 스트리머 필터와 함께 1개의 크래프트 필터 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);

이 기능은 분석기가 필터 속도를 너무 낮추어 회로가 구축된 시스템의 작동이 중단되는 경우에 구출됩니다. 그러한 상황에서는 분석기를 포기하고 메모리 기능의 대체를 사용해야 합니다.

분기를 포함하지 않는 간단한 그래프에 대한 작업 알고리즘을 고려했습니다. 그러나이 접근 방식은 물론 합병증이있는 다른 경우에도 적용될 수 있지만 아이디어는 동일하게 유지됩니다.

다음 글에서는 티커 부하 추정 문제와 미디어 스트리머에서 과도한 컴퓨팅 부하를 처리하는 방법에 대해 살펴보겠습니다.

출처 : habr.com