הגדרת בנצ'מרקינג של תת-מערכת דיסקים: fio, bonnie++, dd

בנצ'מרקינג של תת-מערכת הדיסקים: היכן אובדת הביצועים

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

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

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

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

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

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

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

מה נותן מדידה נכונה: מצבי עומס ומטריקות

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

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

פרופילי עומס: מה ולשם מה למדוד

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

מטריקות שלפיהן מקבלים החלטה

תפוקה (MB/s) עונה על השאלה "האם יספיק להעביר את הנתונים בחלון התחזוקה". השהיה — באחוזון ה-95 וה-99 — עונה על השאלה "האם שאילתות למסד הנתונים לא יתחילו להיתקע בדיסק".

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

במה למדוד: השוואת גישות

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

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

fio

כיצד אנו מבצעים מדידה: שלבי העבודה ההנדסית

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

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

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

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

במה שונה בדיקה סינתטית מעומס אמיתי?

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

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

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

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

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

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

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

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

מקרה בוחן: כיצד מדידות הסירו את הדעיכה של מערך האחסון

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

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

מה הראו המדידות

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

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

מה שינו

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

התוצאה

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

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

ספקות לפני ההתחלה: תאימות, הרשאות, שחזור

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

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

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

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

בסיום העבודה תקבלו לידיכם:

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

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