אופטימיזציה מתקדמת של ליבת לינוקס עם sysctl

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

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

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

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

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

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

הקטגוריות העיקריות שתמצאו ב /proc/sys/ אלה כוללים, בין היתר:

• גַרעִין.*אפשרויות ליבה כלליות (מתזמן, PID, הודעות, NUMA וכו').
• vm.*ניהול זיכרון וירטואלי, החלפה, מטמונים ומדיניות התחייבות יתר.
• נֶטוֹ.*מחסנית רשת IPv4/IPv6, מאגרים של TCP/UDP, תורים, בקרת עומס.
• fs.*: מגבלות של תיאורים, inodes, inotify, התנהגות AIO ו-VFS.
• מפתח*פרמטרים ספציפיים של התקנים ומנהלי התקנים מסוימים.

עם sysctl -a ניתן לפרט את כל הפרמטרים הזמינים, ובעזרת פקודות כמו sysctl vm.swappiness o sysctl net.ipv4.tcp_tw_reuse קריאת ערכים ספציפיים, שהיא המפתח ל ביקורת התצורה הנוכחית לפני שינוי כלשהו. כדי לאתר משהו ספציפי, מקובל לסנן באמצעות grepלדוגמה: sysctl -a | grep tcp.

שינוי פרמטר תוך כדי תנועה הוא פשוט כמו שימוש sysctl -w clave=valorעם זאת, חשוב להבין ששינויים אלה זמניים. כדי לשמור אותם לאחר אתחול מחדש, חיוני לגבות את התצורה ל... /etc/sysctl.conf או בקבצים של /etc/sysctl.d/, בדרך כלל באמצעות קבצים ממוספרים (לדוגמה 10-network.conf, 20-memory.conf, 99-custom.conf) שקובעים את הסדר שבו הם יוחלו.

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

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

ברמה כלל-מערכתית, מומלץ לאסוף סטטיסטיקות של המעבד, העומס, הזיכרון, הדיסק והרשת במשך מספר דקות תחת עומס מייצג. כלים כגון uptime, mpstat, vmstat, iostat -x o sar -n DEV הם מאפשרים לך לראות כיצד הליבה המקורית מתנהגת, כמה swap היא משתמשת, כיצד קלט/פלט של דיסק מגיב, והאם הרשת רוויה או מבזבזת רוחב פס.

בנוסף לסקירה כללית זו, חיוני להריץ מדדי ביצועים ספציפיים עבור האפליקציה שברצונך לייעל. בשרתי אינטרנט, ניתן להשתמש ab (Apache Bench) או כלים דומים למדידה בקשות לשנייה, השהייה ממוצעת ושגיאותבמסדי נתונים, כלי עזר כגון mysqlslap o sysbench הם עוזרים להעריך עסקאות לשנייה וזמני שאילתה.

לדוגמה, בתרחיש ללא כוונון, מקובל למצוא נתונים כמו 500 בקשות HTTP/שנייה עם זמן תגובה ממוצע של 200 אלפיות שנייה, כ-250 שאילתות SQL/שנייה עם זמן השהייה של 40 אלפיות שנייה, מהירות רשת של כ-500 מגה-ביט לשנייה, ועומס מערכת המתקרב לגבול תחת לחץ. מספרים אלה ישמשו כדי לאמת, לאחר יישום שינויים בליבת המערכת, האם מושגת בפועל עלייה מדידה בתפוקה והפחתה בשהייה.

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

הגדרות זיכרון מתקדמות: vm.*

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

פָּרָמֶטֶר vm.swappiness זה שולט בכמות דפי הזיכרון שהליבה שולחת להחלפה. בהפצות רבות, הוא מוגדר ל-60, ערך המיועד לסביבות שולחן עבודה מעורבות. עבור שרתי מסדי נתונים או יישומים בעלי השהייה נמוכה, בדרך כלל עדיף להוריד אותו ל-10 או אפילו פחות, וכתוצאה מכך מערכת יעילה יותר. תן עדיפות לשמירת נתונים ב-RAM וצמצם את ההחלפותלא נדיר לראות את תעבורת הדיסק צונחת ויישומים מגיבים עם הרבה פחות רעידות לאחר התאמה זו.

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

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

מצד, vm.min_free_kbytes שמרו כמות מינימלית של זיכרון פנוי כדי להבטיח שהמערכת תוכל להגיב להתפרצויות הקצאה מבלי לחוות מצבים פתאומיים של "מחוץ לקופסה" (OOB). הגדרת כמות זו לכ-0,5% עד 1% מסך ה-RAM היא בדרך כלל אמצעי בטיחות יעיל כדי למנוע מהליבה להיגמר המקום תחת עומס קיצוני ולהתחיל להרוג תהליכים קריטיים, ובכך לשפר את הביצועים. יציבות כללית של המארח.

לבסוף, מדיניות ההתחייבות היתר ראויה לתשומת לב: פרמטרים כגון vm.overcommit_memory y vm.overcommit_ratio הם קובעים כמה זיכרון וירטואלי מוקצה לתהליכים ביחס ל-RAM הזמין ול-swap. במקרים מסוימים (לדוגמה, עם Redis או מסדי נתונים מסוימים) מותר התחייבות יתר אגרסיבית, בעוד שבמקרים אחרים עדיפה מדיניות שמרנית יותר כדי להגביל את הסיכון ל- OOM ומצבים של זיכרון פגום יתר על המידהלקבלת טכניקות לניתוח ואבחון מקרים מורכבים, התייעץ ניפוי שגיאות זיכרון בלינוקס.

אופטימיזציה מתקדמת של רשת: net.* ו-TCP/IP

מחסנית הרשת היא אולי התחום שבו כוונון מורגש ביותר בסביבות ייצור. שינוי פשוט בתורי החיבור או במאגרים יכול לעשות את ההבדל בין שרת שחונק במהירות של 500 מגה-ביט לשנייה לבין שרת ש... זה בקלות ממלא את הגיגה-ביט.הפרמטרים תחת net.core.* y net.ipv4.* בתחום הזה, הם בעלי בריתך הטובים ביותר.

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

נקודה מרכזית נוספת היא גודל תורי החיבור. פרמטרים כגון net.core.somaxconn, net.core.netdev_max_backlog y net.ipv4.tcp_max_syn_backlog מגבלות אלו מגדירות כמה חיבורים ממתינים המערכת יכולה לטפל בהם לפני שחרור חבילות או דחיית לחיצות יד. בשרתי אינטרנט בעלי תעבורה גבוהה, הגדלת מגבלות אלו יכולה למנוע תורים רוויים ולהפחית באופן דרסטי את העומס. שגיאות חיבור במהלך עומסי שיא.

ניתן גם לכוונן את התנהגות חיבורי TCP באמצעות מגוון אפשרויות: הפעלה net.ipv4.tcp_window_scaling כדי לתמוך בחלונות גדולים בקישורים בעלי רוחב פס גבוה, הפעל net.ipv4.tcp_sack y net.ipv4.tcp_timestamps כדי לשפר את ניהול ההפסדים והשידור החוזר, או להתאים net.ipv4.tcp_fin_timeout והניהול של TIME_WAIT (net.ipv4.tcp_tw_reuse, net.ipv4.tcp_max_tw_buckets) על מנת לשלוט בצריכת משאבים בשרתים עם מיליוני חיבורים קצרים בדקה.

גם בחירת אלגוריתם בקרת עומסים חשובה. cubic זה נשאר ערך ברירת המחדל בהתפלגויות רבות; משתנה ל bbr בליבות מודרניות (4.9 ואילך) על ידי net.ipv4.tcp_congestion_control y net.core.default_qdisc=fq זה יכול להכפיל את תפוקת ה-TCP בסביבות עם הפסדים או השהיות מורכבות, ולהשיג שיפורים של בין פי 2 ל-25 בהשוואה לתצורות קלאסיות בתרחישים מסוימים, במחיר של התנהגות שונה במקצת ברשתות עמוסות.

אסור לנו לשכוח פרמטרים של בטיחות ואמינות כגון net.ipv4.tcp_syncookies, הטיפול בהפניות (net.ipv4.conf.all.accept_redirects, send_redirects) או סינון בגשרים (net.bridge.bridge-nf-call-iptables בסביבות Kubernetes). כאשר הם מוגדרים כראוי, הם מאפשרים לך להגן על המערכת מפני התקפות נפוצות (SYN flood, spoofing וכו') מבלי להתפשר על ביצועי רשת יציביםלמדריך מעשי על כללים וזיהוי, עיינו ב הטמעת Netfilter ו-Suricata.

מערכת קבצים, תיאורים ומגבלות גלובליות: fs.* ו-ulimit

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

גלובלי, fs.file-max זה מציין כמה תיאורים יכולים להיות פתוחים בגרעין בסך הכל. עבור יישומים עם אלפי חיבורים בו זמנית, מקובל להגדיל ערך זה לכמה מיליונים, יחד עם עלייה של fs.nr_openאשר קובע את התקרה הקשוחה עבור תיאורים לכל תהליך. בנוסף, יש צורך בהתאמות. /etc/security/limits.conf כך שלמשתמשים (או שירותים המנוהלים על ידי systemd) יהיה ערכים רכים וקשים התואמים את תצורת הליבה.

תת-המערכת inotify, הנמצאת בשימוש נרחב על ידי IDEs, כלי פיתוח אתרים ומערכות ניטור קבצים, נשלטת על ידי פרמטרים כגון fs.inotify.max_user_watches y fs.inotify.max_user_instancesאם אתם נתקלים בשגיאות הקשורות לצופים או לתהליכים שמפסיקים לנטר שינויים בדיסק, סביר להניח שתצטרכו הגדל את המגבלות הללו כדי למנוע צווארי בקבוק שקטים.

מאפיין רלוונטי נוסף הוא קלט/פלט אסינכרוני (AIO), שהמקסימום הגלובלי שלו מוגדר באמצעות fs.aio-max-nrביישומים המסתמכים במידה רבה על קלט/פלט אסינכרוני (מנועי מסד נתונים מסוימים, מערכות תורים וכו'), הגדלתו מונעת מהליבה להיגמר החריצים עבור פעולות AIO תחת עומס בקשות עצום.

בנוסף לפרמטרים אלה, ביצועי תת-מערכת הדיסק מושפעים על ידי ה- מתזמן קלט/פלט מוגדר בכל התקן בלוק. במערכות עם SSD או NVMe, בדרך כלל מומלץ להשתמש במתזמנים קלים כגון none o mq-deadline, בעוד שבדיסקים מכניים אפשרויות אחרות עשויות להיות הגיוניות, כגון bfq בהתאם לסוג העומס. התאם את המתזמן דרך /sys/block/<disco>/queue/scheduler וכוונון עדין של אפשרויות כגון עומק התור (nr_requests) או את read_ahead_kb יכול לעשות הבדל מורגש ב השהיית קריאה/כתיבה ותפוקהחשוב גם לשקול אילו מערכות קבצים ומנהלי התקנים נמצאים בשימוש; לדוגמה, מאמרים בנושא NTFSplus על לינוקס ומערכות אחרות יכולות לסייע בתכנון עומסים הטרוגניים.

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

ליבה כללית, NUMA, זיקה למעבד ודפי ענק

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

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

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

הדפים הענקיים (vm.nr_hugepagesאלו הם מרכיב מפתח נוסף במערכות מסדי נתונים או עומסי עבודה אחרים המטפלים באזורים גדולים של זיכרון רציף. שמירה על מספר מתאים של דפים ענקיים (2 מגה-בייט או אפילו 1 ג'יגה-בייט, תלוי בארכיטקטורה) יכולה להפחית את תקורת TLB ולשפר משמעותית את ביצועי היישומים הפועלים פעולות רבות על בלוקים גדולים של זיכרוןכדי שזה יהיה יעיל, תצורת הליבה חייבת להיות מתואמת עם היישום עצמו, כך שהוא ישתמש בזיכרון הזה במפורש.

בתחום ההשהיה והתזמון, ישנם פרמטרים של מתזמן כגון kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns o kernel.sched_migration_cost_nsהגדרות אלו מכוונות במדויק את גודל "נתחי" המעבד המוקצים לכל משימה ואת האגרסיביות שבה הליבה מעבירה תהליכים בין ליבות. ערכים קטנים יותר מייצגים מערכת בעלת יכולת דחיפה גבוהה יותר, אשר נוטה להציע... התשובה הטובה ביותר למשימות אינטראקטיביות לעיתים, במחיר של תפוקה גולמית קטנה.

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

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

במקום להשתמש בפתרון קסם אחד, יעיל יותר ליצור פרופילי sysctl המותאמים לסוגים שונים של עומסי עבודה: שרתי אינטרנט, מסדי נתונים, פלטפורמות קונטיינרים או מערכות בעלות השהייה נמוכה. הפצת הגדרות אלו בקבצים כגון 99-webserver.conf, 99-database.conf o 90-kubernetes.conf עזרה ל לשמור על תצורה מאורגנת וקלה לגירסהניתן גם לשקול הפצות ומהדורות מכוונות ביצועים כגון מהדורת שרת CachyOS עבור סביבות ספציפיות מאוד.

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

בצד מסד הנתונים (MySQL, PostgreSQL ודומיו), ניתנת עדיפות לשימוש מינימלי ב-swap, כוונון עדין של כתיבת עמודים מלוכלכים, והגדרות מתאימות של זיכרון משותף וסמפור עבור המנוע. פרמטרים כגון kernel.shmmax, kernel.shmall, kernel.sem ותצורת הדפים הענקית עושה את ההבדל מבחינת עסקאות לשנייה וזמן תגובה, הכפלת ביצועים בשניים או שלושה בהשוואה לערכי ברירת מחדל בתרחישים רבים.

עבור יישומים בעלי השהייה נמוכה במיוחד (מסחר, משחקים מקוונים, עיבוד בזמן אמת), מתווספות הגדרות ספציפיות אף יותר: net.ipv4.tcp_low_latency, ביטול הפעלה איטית לאחר חוסר פעילות, שימוש ב tcp_fastopen, פרמטרים של סקר עסוק (net.core.busy_poll, busy_read) ובמקרים רבים, ביטול עמודים ענקיים שקופים על ידי /sys/kernel/mm/transparent_hugepage/enabledכל זה נועד להפחית את תור העיבוד והשהייה בשיאים באחוזונים גבוהים, ומשיג שיפורים מדהימים ב-P99.

בסביבות קונטיינרים וקוברנטס, מחסנית הרשת ומעקב החיבורים נמצאים תחת לחץ מיוחד. פרמטרים כגון net.ipv4.ip_forward, net.bridge.bridge-nf-call-iptables, net.netfilter.nf_conntrack_maxהשימוש בפורטים שמורים עבור NodePort או התאמת טבלאות ARP נפוצים בצמתים המטפלים במאות או אלפי פודים. התאמתם נכונה מונעת בעיות. חיבורים קטועים, פסקי זמן או רוויה בטבלה עם conntrack.

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

כלי ניטור ויצירת פרופיל ליבה

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

בין השירותים היומיומיים נמצאים vmstat, iostat, sar, ss, slabtop, htop o pidstatאשר מספקים מידע מהיר על תהליכים, CPU, I/O, sockets ושימוש במטמון. בשילוב עם יומני מערכת ומדדים המיוצאים ל-Prometheus, Grafana או collectd, ועם משאבים כגון צג מערכת מתקדם עבור לינוקסהם נותנים תמונה מלאה למדי של התנהגות המארח לפני ואחרי כל כוונון.

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

אם אתם זקוקים לפירוט רב יותר, ftrace תת-מערכת המעקב של הליבה מציעה את היכולת להפעיל נותבי מעקב ספציפיים (לדוגמה, נותב הפונקציות) ולבחון בזמן אמת או לאחר המוות אילו קריאות מתרחשות. הפעלת הנותב המתאים וניתוח תוכנו /sys/kernel/debug/tracing/trace זה מגלה לך נקודות חמות בתוך הליבה עצמהזה מאוד שימושי כאשר מדדים ברמה גבוהה אינם מספיקים.

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

לבסוף, בשלבי בדיקות מאמץ ממושכים (24 ​​שעות או יותר), כלים כגון stress-ng בשילוב עם איסוף מתמשך של מדדים (באמצעות vmstat, iostat, sar) מאפשרים לך להעריך את יציבות המערכת עם תצורת הליבה החדשה, ולוודא שאין אירועי OOM, קריסות, הפעלות מחדש בלתי צפויות או ירידות ביצועים מתמשכות תחת עומס מתמשך.

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