מדריך מתקדם לאופטימיזציה של ליבת לינוקס והפחתת השהייה

אינפורמטק דיגיטל » Recursos » מדריך מתקדם לאופטימיזציה של ליבת לינוקס והפחתת השהייה

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

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

ארכיטקטורת ליבת לינוקס ונקודות מפתח בנוגע להשהייה

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

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

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

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

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

התאמות דרך sysctl לשיפור זמן ההשהיה והביצועים

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

בתחום הרשת, פרמטרים כגון net.core.rmem_max, net.core.wmem_max או net.ipv4.tcp_congestion_control הם משפיעים ישירות על תפוקה, השהייה והתנהגות חיבור TCP. התאמה נכונה של מאגרים ואלגוריתם עומס חיונית עבור שרתי אינטרנט בעלי תעבורה גבוהה או מופעי ענן בעלי השהייה נמוכה.

עבור זיכרון, ערכים כגון vm.swappiness,‏ vm.dirty_ratio,‏ vm.vfs_cache_pressure או vm.overcommit_memory הם מאפשרים לך לשלוט בכמות השימוש ב-swap, כיצד מנוהל מטמון הדף ובהתנהגות הזיכרון הווירטואלי. הפחתת ה-swappiness (לדוגמה, ל-10) בדרך כלל מסייעת במניעת שימוש תכוף מדי ב-swap על ידי המערכת, ובכך מפחיתה קפיצות השהיית קלט/פלט של הדיסק.

אם אתם עובדים עם מסדי נתונים גדולים או יישומים המשתמשים בכמויות עצומות של זיכרון משותף, חשוב להתאים kernel.shmmax, kernel.shmall ומספר הקבצים המרבי שנפתח באמצעות fs.file-max ו- fs.nr_openמגבלות בגודל שגוי אלה עלולות לגרום לצווארי בקבוק ולשגיאות שקשה לאבחן תחת עומס.

הגישה הטובה ביותר היא ליישם שינויים קטנים, למדוד את השפעתם באמצעות כלי ניטור, ורק אז לשמור אותם ב-/etc/sysctl.conf או ב-/etc/sysctl.d/בסביבות קונטיינריות, זכרו שפרמטרי ליבה רבים הם גלובליים למארח: שינוי רשלני שלהם יכול להשפיע על כל השירותים, כך ששילוב sysctl עם cgroups ומרחבי שמות הוא כמעט חובה.

קומפילציה ותחזוקה של ליבות מותאמות אישית

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

תהליך העבודה הקלאסי כולל הורדת קוד מ kernel.org או עצי תיקון כמו xanmod או ליקוריקסולהשתמש בכלים כמו make menuconfig כדי לבחור אפשרויות. שמירת קובץ ה-.config במאגר git משלך, יחד עם סקריפטי בנייה, מאפשרת לך לשחזר קבצי בניה ולשמור על עקביות בין גרסאות.

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

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

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

כדי להימנע מבזבוז חצי מהחיים שלך בקומפילציה, הגיוני לבצע את הבנייה על מכונה חזקה יותר, ובמידת הצורך להשתמש הידור צולב (לדוגמה, קומפילציה של ליבה של 32 סיביות עבור Atom ממחשב x86_64 פשוט על ידי התאמת ARCH ושרשראות הכלים המתאימות). לאחר מכן, כל שעליך לעשות הוא להתקין את קבצי ה-.deb במחשב היעד ולהוסיף את הערך המתאים ל-GRUB.

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

מודלים של Preemption ותיקוני PREEMPT_RT עבור מערכות בעלות השהייה נמוכה

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

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

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

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

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

כוונון תזמון המעבד, פעולה ללא טיקים ובידוד ליבות

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

Red Hat Enterprise Linux 8, לדוגמה, מגיע עם ליבה ללא טיקים כברירת מחדל עבור מעבדים סרקזה מפחית את צריכת האנרגיה על ידי הימנעות מהפרעות תקופתיות כאשר הליבה במצב סרק. ניתן להפעיל מצב עבור עומסי עבודה הרגישים להשהייה. דינמי ללא טיקים בקבוצת גרעיניםכך שרק מעבד אחד ("ליבת הבית") מטפל ברוב המשימות מבוססות הזמן, והשאר נקיים ככל האפשר מהפרעות תקופתיות.

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

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

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

ניהול זיכרון ואחסון עם דגש על השהייה

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

בצד הזיכרון, צמצמו vm.swappiness למזער את השימוש ב-swap (שהוא כמעט תמיד איטי בהרבה מ-RAM), vm.vfs_cache_pressure הוא שולט במהירות שבה המערכת מנסה לנקות את מטמון ה-inode וה-dentry, ו vm.nr_hugepages זה מאפשר לשמור HugePages סטטיים לעומסים כבדים כמו מסדי נתונים או JVMs, מה שמפחית את תקורת TLB.

באחסון, בחר את מתזמן קלט/פלט מתאים בהתאם לסוג הדיסק זה קריטי. בכונני SSD מודרניים, בדרך כלל מומלץ להשתמש... none o mq-deadlineבעוד שבדיסקים מכניים ומערכות מרובות משימות, אלגוריתמים שנועדו להגינות עשויים להיות טובים יותר, כגון Bfqבנוסף, הרכבת מערכות קבצים עם אפשרויות כגון noatime y nodiratime הימנעו מכתיבות מיותרות בכל פעם שניגשים לקובץ או ספרייה.

לגבי מערכות קבצים, ext4 ו-XFS אלו נותרות האפשרויות הנפוצות ביותר: ext4 מכוון היטב הוא הימור בטוח, בעוד ש-XFS נוטה להתרחב טוב יותר תחת מקביליות גבוהה. עבור תרחישים תובעניים מאוד, שילוב של RAID (RAID 10 עבור מסדי נתונים, RAID 0 עבור אחסון זמני) עם מתזמן טוב יכול להפחית את ההשהיה הממוצעת, ומעל הכל, את השונות.

אופטימיזציה של רשת וקרנל עבור השהייה נמוכה בלינוקס וב-EC2

ביישומי רשת בעלי ביצועים גבוהים, זמן ההשהיה תלוי לא רק בחומרה או במרחק, אלא גם ב... כיצד מוגדרים מחסנית ה-TCP/IP והליבה עצמהזה ניכר במיוחד במקרים של ענן כמו Amazon EC2 עם ממשקי ENA.

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

בתוך הליבה, תצורת הרשת כרוכה בהגדלת תיאורי קבצים (ulimit -n), גודל מאגרים של קבלה ושליחה עם net.core.rmem_max, net.core.wmem_max, net.ipv4.tcp_rmem, net.ipv4.tcp_wmemולהפעיל אפשרויות כגון TCP מהיר לפתוח כדי להפחית את זמן ההשהיה של יצירת החיבור.

בממשקי AWS ENA, לניהול פסיקות תפקיד חשוב: כברירת מחדל, הדרייבר מקבץ חבילות כדי להפחית את מספר ה-IRQs. תרופות מרשם ותרופות טקסונומיותאם ברצונך להפחית את ההשהיה למינימום המוחלט, תוכל להשבית את הניהול הזה על ידי ethtool -Cהגדרת rx-usecs ו-tx-usecs לאפס מורידה את ההשהיה אך מגדילה את תקורת הפסיקות, לכן יש למצוא איזון בהתאם לעומס.

ניתן להשתמש בו גם irqbalance לחלוקת IRQs על פני מספר ליבות, או להשבית אותו ולהגדיר ידנית זיקה של פסיקות ותור רשת (RSS/RPS) לליבות ספציפיות, דבר אופייני מאוד בסביבות עם השהייה נמוכה במיוחד או בעת שימוש ב-DPDK ודילוג על חלק ניכר ממחסנית הליבה.

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

אופטימיזציה של המעבד, השירות והיישומים להפחתת השהייה

מלבד הליבה עצמה, לסביבה שמסביב יש הרבה מה לומר על ההשהיה הכוללת: החל מ- שירותים פעילים במערכת עד לתצורה הספציפית של כל יישום.

שרת בעל ביצועים גבוהים אמור להריץ רק את שדים שבאמת נחוציםשירותים כמו בלוטות', הדפסה או גילוי אוטומטי של רשת (CUPS, Avahi וכו') במחשבים אחוריים צורכים רק את המעבד, הזיכרון והקלט/פלט מבלי לספק כל תועלת. סקור עם systemctl list-unit-files --state=enabled והשבתת דברים מיותרים היא אחד הדברים הזולים והיעילים ביותר שאפשר לעשות.

כדי לתעדף תהליכים קריטיים, ניתן להשתמש בכלים כגון רניס, קריט ומערכת משימותהתאמת סדרי עדיפויות של תהליך (renice), מתן תזמון בזמן אמת (chrt -f 99), או הקצאתו לליבות ספציפיות (taskset) מפחיתים הפרעות למשימות אחרות, ומשפרים את יכולת החיזוי של המעבד עבור מסדי נתונים, VoIP, סטרימינג או שירותי מסחר.

ברמת האפליקציה, כוונון חשוב בדיוק כמו כוונון ליבה. שרתי אינטרנט כמו Nginx או Apache הם צריכים כוונון עדין של workers, keepalive, caches ודחיסה. מסדי נתונים כמו PostgreSQL או MySQL עליהם לבדוק את גדלי המאגר, נקודות הביקורת, מאגר החיבורים ופרמטרי כתיבה סינכרוניים כדי להשיג השהיות נמוכות ויציבות.

גם ל-JVMs תפקיד: בחירת אוספי אשפה כמו G1GC או ZGC התאמת גדלי ערימה יכולה להפחית השהיות אשר, מנקודת מבט חיצונית, נראות כהשהיה. בסביבות וירטואליות ומכולות, חלוקה נכונה היא קריטית. מכסות vCPU, vRAM ו-I/O זה מונע מחלוקת שקטה שמופיעה מאוחר יותר כתורים אינסופיים על הדיסק או במעבד רווי.

ניטור וביצועי ביצועים של ליבה ומערכת

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

כדי לראות את המצב הכללי של המערכת, ניתן להשתמש בכלים קלאסיים כגון htop, vmstat, iotop o sarכאשר אתם זקוקים לפרטים נוספים, כלי ליבה ספציפיים נכנסים לתמונה, כגון ביצועים ו-ftraceאשר מאפשרים לך לעקוב אחר התנהגות המתזמן, הפסיקות והקריאות הפנימיות בדיוק רב.

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

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

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

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