חקר מנוע ה-VoIP Mediastreamer2. חלק 12

החומר של המאמר לקוח ממני ערוץ זן.

בעבר статье, הבטחתי לשקול את נושא הערכת העומס על הטיקר ודרכים להילחם בעומס מחשוב מופרז בסטרימר המדיה. אבל החלטתי שזה יהיה הגיוני יותר לכסות את הנושאים של איתור באגים במסנני מלאכה הקשורים לתנועת נתונים ורק אז לשקול סוגיות של אופטימיזציה של ביצועים.

איתור באגים מסנני מלאכה

אחרי שבדקנו את המנגנון להעברת נתונים בסטרימר מדיה במאמר הקודם, יהיה הגיוני לדבר על הסכנות החבויות בו. אחת התכונות של עקרון "זרימת הנתונים" היא שזיכרון מוקצה מהערימה במסננים הממוקמים במקור זרימת הנתונים, והזיכרון משתחרר ומוחזר לערימה על ידי מסננים הממוקמים בסוף הזרימה. נָתִיב. בנוסף, יצירת נתונים חדשים והשמדתם יכולים להתרחש איפשהו באמצע. באופן כללי, שחרור הזיכרון מתבצע על ידי מסנן שונה מזה שיצר את בלוק הנתונים.

מנקודת מבט של ניטור זיכרון שקוף, יהיה סביר שהמסנן, עם קבלת בלוק קלט, ישמיד אותו מיד לאחר עיבוד, שחרור הזיכרון ויוציא בלוק חדש שנוצר עם נתוני פלט. במקרה זה, דליפת זיכרון במסנן תתגלה בקלות - אם המנתח זיהה דליפה במסנן, אז המסנן הבא לא הורס בלוקים נכנסים כמו שצריך ויש בו שגיאה. אבל מנקודת המבט של שמירה על ביצועים גבוהים, גישה זו לעבודה עם בלוקי נתונים אינה פרודוקטיבית - היא מובילה למספר רב של פעולות להקצאת/פינוי זיכרון לבלוקי נתונים ללא כל פלט שימושי.

מסיבה זו, מסנני מדיה סטרימר, על מנת לא להאט את עיבוד הנתונים, משתמשים בפונקציות היוצרות העתקות קלות בעת העתקת הודעות (דיברנו עליהן במאמר הקודם). פונקציות אלו יוצרות מופע חדש של כותרת ההודעה רק על ידי "צירוף" אליה בלוק נתונים מההודעה "הישנה" המועתקת. כתוצאה מכך, שתי כותרות מחוברות לבלוק נתונים אחד ומונה ההתייחסות בבלוק הנתונים מוגדל. אבל זה ייראה כמו שתי הודעות. יכולות להיות יותר הודעות עם בלוק נתונים "חברתי" כזה, למשל, מסנן MS_TEE יוצר תריסר עותקים קלים כאלה בבת אחת, ומפיץ אותם בין הפלטים שלו. אם כל המסננים בשרשרת פועלים כהלכה, עד סוף הצינור אמור מונה ההתייחסות הזה להגיע לאפס ופונקציית שחרור הזיכרון תיקרא: ms_free(). אם השיחה לא תתרחש, אז פיסת הזיכרון הזו לא תוחזר יותר לערימה, כלומר. זה "ידלוף". המחיר לשימוש בעותקים קלים הוא אובדן היכולת לקבוע בקלות (כפי שיהיה במקרה של עותקים רגילים) איזה מסנן גרף דולף זיכרון.

מכיוון שמפתחי סטרימר המדיה אחראים לאיתור דליפות זיכרון במסננים מקוריים, סביר להניח שלא תצטרך לנפות אותם. אבל עם מסנן היצירה שלך, אתה החגב של האושר שלך, והזמן שאתה מבלה בחיפוש אחר דליפות בקוד שלך יהיה תלוי בדיוק שלך. כדי להפחית את זמן איתור הבאגים שלך, עלינו לבחון טכניקות זיהוי דליפות בעת פיתוח מסננים. בנוסף, יכול לקרות שהדליפה תתבטא רק כאשר הפילטר מיושם במערכת אמיתית, שבה מספר ה"חשודים" עשוי להיות עצום והזמן לניפוי באגים מוגבל.

כיצד מתבטאת דליפת זיכרון?

זה הגיוני להניח כי בפלט התוכנית חלק עליון יציג את אחוז הזיכרון ההולך וגובר שנכבש על ידי היישום שלך.

הביטוי החיצוני יהיה שבשלב מסוים המערכת תתחיל להגיב לאט לתנועת העכבר ולאט לאט תצייר מחדש את המסך. ייתכן גם שיומן המערכת יגדל ויאכל מקום בכונן הקשיח שלך. במקרה זה, האפליקציה שלך תתחיל להתנהג בצורה מוזרה, לא תגיב לפקודות, לא תוכל לפתוח קובץ וכו'.

כדי לזהות התרחשות דליפה, נשתמש בנתח זיכרון (להלן מנתח). זה יכול להיות ואלגרינד (טוֹב מאמר על זה) או מובנה במהדר gcc MemorySnitizer או משהו אחר. אם המנתח מראה שמתרחשת דליפה באחד ממסנני הגרפים, אז זה אומר שהגיע הזמן ליישם אחת מהשיטות המתוארות להלן.

שיטת שלושת האורנים

כפי שהוזכר לעיל, אם יש דליפת זיכרון, המנתח יצביע על המסנן שביקש הקצאת זיכרון מהערימה. אבל זה לא יצביע על המסנן ש"שכח" להחזיר אותו, שלמעשה הוא האשם. לפיכך, המנתח יכול רק לאשר את הפחדים שלנו, אך לא להצביע על השורש שלהם.

כדי לברר את מיקומו של המסנן ה"רע" בגרף, ניתן לבצע צמצום הגרף למספר המינימלי של צמתים שבהם המנתח עדיין מזהה דליפה ולמקם את המסנן הבעייתי בשלושת האורנים הנותרים.

אבל יכול לקרות שעל ידי הפחתת מספר המסננים בגרף, תשבש את מהלך האינטראקציה הרגיל בין מסננים ואלמנטים אחרים של המערכת שלך והדליפה לא תופיע יותר. במקרה זה, תצטרך לעבוד עם גרף בגודל מלא ולהשתמש בגישה המתוארת להלן.

שיטת בידוד הזזה

לפשטות המצגת, נשתמש בגרף המורכב משרשרת אחת של מסננים. היא מוצגת בתמונה.

גרף רגיל בו, לצד מסנני סטרימר מדיה מוכנים, נעשה שימוש בארבעה מסנני craft F1...F4, מארבעה סוגים שונים, אותם הכנתם מזמן ואין לכם ספק בנכונותם. עם זאת, הבה נניח שלכמה מהם יש דליפות זיכרון. הפעלת התוכנית שלנו לניטור המנתח, אנו למדים מהדוח שלו שמסנן מסוים ביקש כמות מסוימת של זיכרון ולא החזיר אותו ל-Hap 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