הגדרת ליבת לינוקס עבור GlusterFS

תרגום המאמר הוכן ערב תחילת הקורס "מנהל מערכת לינוקס. מקצועי".

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

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

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

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

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

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

vm.swappiness

פרמטר vm.swappiness קובע כמה הליבה משתמשת ב-swap בהשוואה ל-RAM. זה גם מוגדר בקוד המקור כ"נטייה לגנוב זיכרון ממופה". ערך החלפה גבוה אומר שהקרנל יהיה נוטה יותר להחליף דפים ממופים. ערך החלפה נמוך אומר ההפך: הקרנל יחליף פחות דפים מחוץ לזיכרון. במילים אחרות, ככל שהערך גבוה יותר vm.swappiness, ככל שהמערכת תשתמש יותר ב-swap.

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

אתה יכול לקרוא עוד כאן - lwn.net/Articles/100978

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

vm.vfs_cache_pressure

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

עם ערך ברירת המחדל של 100, הליבה תנסה לשחרר את מטמוני ה-dentry וה-inode בצורה הוגנת ל-pagecache ול-swapcache. הפחתת vfs_cache_pressure גורמת לגרעין לשמר מטמון שיניים ואינוד. כאשר הערך הוא "0", הקרנל לעולם לא ישטוף את מטמון השיניים והאינוד עקב לחץ זיכרון, וזה יכול בקלות להוביל לשגיאה מחוץ לזיכרון. הגדלת vfs_cache_pressure מעל 100 גורמת לקרנל לתת עדיפות לדנטריה ואינוד.

בעת שימוש ב-GlusterFS, משתמשים רבים עם כמויות גדולות של נתונים והרבה קבצים קטנים יכולים להשתמש בקלות בכמות משמעותית של זיכרון RAM בשרת עקב מטמון inode/dentry, מה שעלול להוביל לביצועים גרועים מכיוון שהקרנל צריך לטפל במבני נתונים במערכת. עם 40 GB זיכרון. הגדרת פרמטר זה ליותר מ-100 סייעה למשתמשים רבים להשיג שמירה הוגנת יותר במטמון ותגובתיות הליבה משופרת.

vm.dirty_background_ratio ו-vm.dirty_ratio

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

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

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

"1"> /proc/sys/vm/pagecache

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

"דדליין" > /sys/block/sdc/queue/scheduler

מתזמן ה-I/O הוא רכיב של ליבת לינוקס שמטפל בתורי קריאה וכתיבה. בתיאוריה, עדיף להשתמש ב-"noop" עבור בקר RAID חכם, כי לינוקס לא יודעת דבר על הגיאומטריה הפיזית של הדיסק, ולכן יעיל יותר לתת לבקר, שמכיר היטב את גיאומטריית הדיסק, לעבד את הבקשה בתור מהר ככל האפשר. אבל נראה ש"דדליין" משפר את הביצועים. מידע נוסף על מתזמנים ניתן למצוא בתיעוד עבור קוד המקור של ליבת לינוקס: linux/Documentation/block/*osched.txt. וגם ראיתי עלייה בתפוקת הקריאה במהלך פעולות מעורבות (הרבה כתיבה).

"256" > /sys/block/sdc/queue/nr_requests

מספר בקשות ה-I/O במאגר לפני שליחתן למתזמן. גודל התור הפנימי של חלק מהבקרים (queue_depth) גדול יותר מה-nr_requests של מתזמן ה-I/O, כך שלמתזמן ה-I/O יש סיכוי קטן לתעדף נכון ולמזג בקשות. עבור מתזמני מועד ו-CFQ, עדיף כאשר nr_requests גדול פי 2 מהתור הפנימי של הבקר. מיזוג וסדר מחדש של שאילתות עוזרים למתזמן להיות מגיב יותר תחת עומס רב.

echo "16" > /proc/sys/vm/page-cluster

פרמטר ה-page-cluster שולט במספר הדפים שנכתבים ל-swap בבת אחת. בדוגמה שלמעלה, הערך מוגדר ל-"16" כדי להתאים לגודל פס ה-RAID של 64 KB. זה לא הגיוני כאשר החלפה = 0, אבל אם תגדיר את ההחלפה ל-10 או 20, אז השימוש בערך זה יעזור לך כאשר גודל פס ה-RAID הוא 64 KB.

blockdev --setra 4096 /dev/<devname> (-sdb, hdc או dev_mapper)

הגדרות ברירת המחדל של התקן החסימה עבור בקרי RAID רבים גורמות לרוב לביצועים איומים. הוספת האפשרות לעיל מגדירה קריאה קדימה עבור סקטורים של 4096*512 בתים. לפחות עבור פעולות סטרימינג, המהירות מוגברת על ידי מילוי מטמון הדיסק שבשבב באמצעות קריאה קדימה במהלך התקופה שבה משתמש הליבה להכנת I/O. המטמון יכול להכיל נתונים שיתבקשו במהלך הקריאה הבאה. יותר מדי קריאה קדימה יכולה להרוג קלט/פלט אקראי עבור קבצים גדולים אם הוא מנצל את זמן הדיסק שעלול להיות שימושי או טוען נתונים מחוץ למטמון.

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

-> ext4 fs, 5 disks, 64K stripe, units in 4K blocks
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disks, 64K stripe, units in 512-byte sectors
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))

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

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

מאפייני מידע:

• dom.as/2008/02/05/linux-io-schedulers
• www.nextre.it/oracledocs/oraclemyths.html
• lkml.org/lkml/2006/11/15/40
• misterd77.blogspot.com/2007/11/3ware-hardware-raid-vs-linux-software.html

קרא עוד

• שימוש ב-nftables ב-Red Hat Enterprise Linux 8

מקור: www.habr.com