הגדרת מתזמן קלט/פלט בלינוקס: התאמת מתזמן ל-NVMe, SSD, HDD

מתזמן קלט/פלט: היכן תור המשימות מאט את הדיסקים

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

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

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

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

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

מה משתנה בעבודת הדיסקים לאחר התאמת המצב

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

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

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

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

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

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

התוצאה השלישית, הבולטת ביותר עבור הלוגיקה העסקית — יציבות התגובה של יישומים. נעלם סוג הכשלים «הדיסק עסוק, היישום ממתין»: הבקשה אינה נתקעת בשיא, משום שהתור תוכנן עבורה.

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

בחירת מתזמן עבור NVMe, SSD ו-HDD

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

הבחירה היא פשרה בין תפוקה, השהיה והגינות בין תהליכים, ולא חיפוש אחר האפשרות «המהירה ביותר». בליבת Linux זמינים כמה מתזמנים, והם מוחלפים בהתקן פעיל, בלי אתחול מחדש.

בנפרד בודקים את מצב סידור הבקשות מחדש: ב-HDD וב-SATA SSD איחוד בלוקים שכנים מפחית את מספר הפעולות, ואילו ב-NVMe הוא משכפל את עבודת הבקר ומוסיף תקורה. את האפשרות הסופית בוחרים לפי מדידות על פרופיל עומס אמיתי — סינתטיקה על דיסק ריק כמעט תמיד משקרת.

סדר היישום: מביקורת עומס ועד מסירת נוהל

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

1. ביקורת עומס על הדיסק. מודדים את עומק התור, יחס הקריאה והכתיבה, גודל הבקשה וזמן התגובה לפי כל התקן — זה הבסיס שמולו משווים את כל השאר.
2. סכמת תורים. מסמנים דיסקים לפי ייעוד ומחשבים כמה תורים נופלים על התקן ואיפה צוואר הבקבוק: אמצעי האחסון עצמו או התור אליו.
3. התאמת המצב. ב-NVMe סידור בקשות מחדש כמעט אינו מניב רווח, ב-SSD עם תורים מקבילים עובד מצב רב-זרימתי, וב-HDD — עם צבירה ומיון בקשות.
4. סטנד לבדיקת המצב. פורסים עותק של הסביבה, חוזרים על הפרופיל מהביקורת ומשווים השהיה ותפוקה מול הבסיס. מצב בלי רווח בסטנד אינו עולה לצומת הייצור.
5. החלפה לפי צמתים. משנים בשלבים, עם אפשרות חזרה בצעד אחד, ומיד מקבעים את הכלל בקונפיגורציה — אחרת לאחר אתחול או עדכון ליבה הערך יחזור לקדמותו.
6. בדיקה בתעבורה אמיתית. בודקים התנהגות בשיא ובשעות עומס נמוך: זמן תגובה, אורך תור, רגרסיה בשירותים שכנים.
7. מסירת נוהל תחזוקה. מוסרים מסמך: איזה מצב מתאים לאיזה סוג דיסק, כיצד לבדוק את הערך הנוכחי, כיצד לחזור אחורה ואילו מטריקות לצפות.

ערכת תיעוד והגדרות בפלט

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

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

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

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

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

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

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

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

מטריקות לפני ואחרי: זמן ההמתנה לפעולות דיסק באחוזון ה-99 הצטמצם פי 6–8, ושיעור ההמתנה לקלט/פלט ירד מרבע ל-2–3%. נפסקו הצניחות התקופתיות בתגובה — במקום קפיצות מדי כמה דקות הגרף התיישר, וחלון הגיבוי התקצר עד כדי כך שהפסיק לחפוף לעומס השיא. הצומת הפסיק להיתקע בדיסק, ונשארה רזרבה לעומס על אותה חומרה.

מה לעשות אם בצומת מעורבים בסיס נתונים ומשימות קבצים?

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

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

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

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

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

ספקות טכניים לפני החלפת מצב עיבוד התור

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

האם יש סיכון לאבד נתונים?

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

מה לעשות בעת החלפת אמצעי אחסון?

דיסק חדש מגיע עם מצב ברירת מחדל — מכאן «אחרי ההחלפה זה נעשה איטי יותר». את הכלל מצמידים לסוג המדיה, ולא לשם ההתקן: NVMe, SATA SSD ו-HDD מקבלים את המצבים שלהם אוטומטית. אז החלפת דיסק או הוספת צומת אינן דורשות הגדרה ידנית.

כיצד לחזור אחורה אם המצב הורע?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

להתחלה שלחו:

• הרכב הצמתים וסוגי המדיה — NVMe, SATA SSD, HDD והתפקיד שלהם במערכת;
• פרופיל העומס: בסיס נתונים, תורי הודעות, אחסון קבצים, וירטואליזציה;
• התרחיש הנוכחי — איזה מתזמן נבחר וכיצד הוגדרו פרמטרי התור;
• סימפטום עם מספרים: צניחות בכתיבה, עלייה בזמן התגובה, עומס לא אחיד על הליבות;
• מגבלות — חלון תחזוקה, דרישות לחזרה אחורה ונוהלים פנימיים;
• סטנד או שרת שבהם אפשר לשחזר את ההתנהגות לפני שינויים בסביבת הייצור.

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

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

תארו את המשימה — נחזור עם הערכה ותוכנית.