สำรวจเครื่องมือ Mediastreamer2 VoIP ส่วนที่ 12

เนื้อหาของบทความนำมาจากของฉัน ช่องเซน.

ในที่สุด статьеฉันสัญญาว่าจะพิจารณาปัญหาของการประมาณการโหลดทิกเกอร์และวิธีจัดการกับโหลดคอมพิวเตอร์ที่มากเกินไปในสตรีมมีเดีย แต่ฉันตัดสินใจว่าจะมีเหตุผลมากกว่าที่จะครอบคลุมประเด็นของการดีบักตัวกรองงานฝีมือที่เกี่ยวข้องกับการเคลื่อนย้ายข้อมูล แล้วจึงพิจารณาเฉพาะปัญหาการเพิ่มประสิทธิภาพการทำงาน

การดีบักตัวกรองงานฝีมือ

หลังจากที่เราได้ตรวจสอบกลไกการเคลื่อนย้ายข้อมูลในสตรีมมีเดียในบทความที่แล้ว คงจะมีเหตุผลที่จะพูดถึงอันตรายที่ซ่อนอยู่ในนั้น คุณลักษณะอย่างหนึ่งของหลักการ "โฟลว์ข้อมูล" คือการจัดสรรหน่วยความจำจากฮีปเกิดขึ้นในตัวกรองที่อยู่ต้นทางของโฟลว์ข้อมูล และตัวกรองที่อยู่ส่วนท้ายของเส้นทางโฟลว์จะจัดสรรหน่วยความจำคืนแล้ว ไปที่กอง นอกจากนี้ การสร้างข้อมูลใหม่และการทำลายข้อมูลอาจเกิดขึ้นที่ใดที่หนึ่งในจุดกึ่งกลาง โดยทั่วไป การปล่อยหน่วยความจำจะดำเนินการโดยตัวกรองอื่นที่ไม่ใช่ตัวกรองที่สร้างบล็อกข้อมูล

จากมุมมองของการตรวจสอบหน่วยความจำอย่างโปร่งใส เมื่อได้รับบล็อกอินพุตตัวกรองจะมีเหตุผลที่จะทำลายทันทีหลังการประมวลผล เพิ่มหน่วยความจำ และวางบล็อกที่สร้างขึ้นใหม่พร้อมข้อมูลเอาต์พุตบนเอาต์พุต ในกรณีนี้ สามารถติดตามการรั่วไหลของหน่วยความจำในตัวกรองได้อย่างง่ายดาย — หากเครื่องวิเคราะห์ตรวจพบการรั่วไหลในตัวกรอง ตัวกรองที่ตามมาจะไม่ทำลายบล็อคขาเข้าอย่างเหมาะสมและมีข้อผิดพลาดเกิดขึ้น แต่จากมุมมองของการรักษาประสิทธิภาพสูง วิธีการทำงานกับบล็อกข้อมูลนี้ไม่ได้ผล - นำไปสู่การดำเนินการจำนวนมากเพื่อจัดสรร / หน่วยความจำว่างสำหรับบล็อกข้อมูลโดยไม่มีการหมดประโยชน์

ด้วยเหตุนี้ Media Streamer จึงกรองเพื่อไม่ให้การประมวลผลข้อมูลช้าลง เมื่อคัดลอกข้อความจะใช้ฟังก์ชันที่สร้างสำเนาขนาดเล็ก (เราได้พูดถึงในบทความก่อนหน้านี้) ฟังก์ชันเหล่านี้สร้างสำเนาใหม่ของส่วนหัวของข้อความโดย "แนบ" บล็อกข้อมูลจากข้อความ "เก่า" ที่คัดลอกไปเท่านั้น เป็นผลให้มีการแนบสองส่วนหัวเข้ากับบล็อกข้อมูลเดียวและตัวนับอ้างอิงในบล็อกข้อมูลจะเพิ่มขึ้น แต่จะมีลักษณะเป็นสองข้อความ อาจมีข้อความเพิ่มเติมที่มีบล็อกข้อมูล "สาธารณะ" เช่น ตัวกรอง MS_TEE จะสร้างสำเนาแสงดังกล่าวสิบชุดในคราวเดียว โดยกระจายไปยังเอาต์พุต หากตัวกรองทั้งหมดในเชนทำงานได้อย่างถูกต้อง ในตอนท้ายของไปป์ไลน์ จำนวนการอ้างอิงนี้ควรถึงศูนย์ และฟังก์ชันการจัดสรรคืนหน่วยความจำจะถูกเรียกใช้: ms_free(). หากการโทรไม่เกิดขึ้น หน่วยความจำส่วนนี้จะไม่ถูกส่งคืนไปยังฮีปอีกต่อไป นั่นคือ เขา "รั่วไหล" ต้นทุนของการใช้สำเนาน้อยคือการสูญเสียความสามารถในการระบุได้ง่าย (เช่นเดียวกับในกรณีของการใช้สำเนาปกติ) ซึ่งกราฟจะกรองหน่วยความจำที่รั่วไหล

เนื่องจากความรับผิดชอบในการค้นหาการรั่วไหลของหน่วยความจำในตัวกรอง "เนทีฟ" นั้นเป็นของผู้พัฒนาสตรีมมีเดีย ดังนั้นเป็นไปได้มากว่าคุณจะไม่ต้องดีบักพวกมัน แต่ด้วยตัวกรองการประดิษฐ์ของคุณ คุณเองคือตั๊กแตนแห่งความสุขของคุณเอง และเวลาที่คุณใช้ในการค้นหารอยรั่วในโค้ดของคุณจะขึ้นอยู่กับความถูกต้องของคุณ เพื่อลดเวลาในการดีบั๊กของคุณ เราจำเป็นต้องดูเทคนิคการแปลการรั่วไหลเมื่อออกแบบตัวกรอง นอกจากนี้ อาจเกิดขึ้นได้ที่การรั่วไหลจะแสดงออกมาเฉพาะเมื่อใช้ตัวกรองในระบบจริง ซึ่งจำนวน "ผู้ต้องสงสัย" อาจมาก และเวลาในการดีบักมีจำกัด

หน่วยความจำรั่วแสดงออกมาได้อย่างไร?

มันเป็นตรรกะที่จะถือว่าในผลลัพธ์ของโปรแกรม ด้านบน จะแสดงเปอร์เซ็นต์ที่เพิ่มขึ้นของหน่วยความจำที่แอปพลิเคชันของคุณครอบครอง

การสำแดงภายนอกจะประกอบด้วยความจริงที่ว่าในบางจุดระบบจะตอบสนองต่อการเคลื่อนไหวของเมาส์อย่างช้าๆโดยวาดหน้าจอใหม่อย่างช้าๆ อาจเป็นไปได้ว่าบันทึกของระบบจะเพิ่มขึ้น กินพื้นที่ในฮาร์ดไดรฟ์ ในกรณีนี้ แอปพลิเคชันของคุณจะเริ่มทำงานผิดปกติ ไม่ตอบสนองต่อคำสั่ง เปิดไฟล์ไม่ได้ เป็นต้น

ในการระบุข้อเท็จจริงของการรั่วไหล เราจะใช้ตัววิเคราะห์หน่วยความจำ (ต่อไปนี้จะเรียกว่าตัววิเคราะห์) มันอาจจะเป็น วาลกรินด์ (ดี บทความ เกี่ยวกับมัน) หรือสร้างขึ้นในคอมไพเลอร์ gcc MemorySanitizer หรืออย่างอื่น. หากเครื่องวิเคราะห์แสดงว่าการรั่วไหลเกิดขึ้นในตัวกรองกราฟตัวใดตัวหนึ่ง แสดงว่าถึงเวลาที่จะต้องใช้วิธีใดวิธีหนึ่งที่อธิบายไว้ด้านล่าง

วิธีทรีไพน์

ตามที่กล่าวไว้ข้างต้น ในกรณีที่หน่วยความจำรั่ว ตัววิเคราะห์จะชี้ไปที่ตัวกรองที่ร้องขอการจัดสรรหน่วยความจำจากฮีป แต่จะไม่ชี้ไปที่ตัวกรองที่ "ลืม" เพื่อส่งคืนซึ่งอันที่จริงแล้วคือการตำหนิ ดังนั้น เครื่องวิเคราะห์จึงสามารถยืนยันความกลัวของเราได้เท่านั้น แต่ไม่สามารถชี้ไปที่ต้นตอของความกลัวได้

หากต้องการทราบตำแหน่งของตัวกรองที่ "ไม่ดี" ในกราฟ คุณสามารถดำเนินการโดยการลดกราฟให้เหลือจำนวนโหนดต่ำสุดที่เครื่องวิเคราะห์ยังคงตรวจพบการรั่วไหล และค้นหาตัวกรองที่มีปัญหาใน XNUMX ต้นสนที่เหลือ

แต่อาจเกิดขึ้นได้โดยการลดจำนวนตัวกรองในคอลัมน์ คุณจะขัดขวางการโต้ตอบตามปกติระหว่างตัวกรองและองค์ประกอบอื่นๆ ในระบบของคุณ และการรั่วไหลจะไม่ปรากฏอีกต่อไป ในกรณีนี้ คุณจะต้องทำงานกับกราฟขนาดเต็มและใช้วิธีการที่อธิบายไว้ด้านล่าง

วิธีลูกถ้วยเลื่อน

เพื่อความง่ายในการนำเสนอ เราจะใช้กราฟที่ประกอบด้วยตัวกรองชุดเดียว เธอแสดงอยู่ในภาพ

กราฟธรรมดาซึ่งใช้ร่วมกับตัวกรองสตรีมสื่อสำเร็จรูป ตัวกรองงานฝีมือสี่ตัว 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);

คุณลักษณะนี้เข้ามาช่วยในกรณีที่เครื่องวิเคราะห์ทำให้ตัวกรองทำงานช้าลงมากจนการทำงานของระบบที่สร้างวงจรของเราหยุดชะงัก ในสถานการณ์เช่นนี้ คุณต้องละทิ้งเครื่องวิเคราะห์และใช้ฟังก์ชันหน่วยความจำทดแทน

เราได้พิจารณาอัลกอริทึมของการดำเนินการสำหรับกราฟอย่างง่ายที่ไม่มีสาขา แต่แนวทางนี้สามารถนำไปใช้กับกรณีอื่นๆ ได้ แน่นอนว่ามีความยุ่งยาก แต่แนวคิดยังคงเหมือนเดิม

ในบทความถัดไป เราจะพิจารณาปัญหาของการประมาณการโหลดทิกเกอร์และวิธีจัดการกับโหลดการประมวลผลที่มากเกินไปในสตรีมมีเดีย

ที่มา: will.com