בדיקת אחסון שימושית מתאימה את גודל הפעולה, דפוס הגישה, המקביליות ודרישות העמידות לאפליקציה. תעדו את תנאי הבדיקה ואת התפלגות ההשהיה, ואז אמתו את התוצאה עם מדידות מהאפליקציה.
התחל בשאלת אחסון, לא בציון
החליטו מה אתם צריכים לדעת לפני הרצת בנצ'מרק. ייתכן שאתם חוקרים קומיטים איטיים של מסד נתונים, תפוקת הפצת קבצים או תהליך בנייה שיוצר קבצים קטנים רבים. עומסי עבודה אלה אינם מבקשים מהדיסק לעשות את אותו הדבר. העתקה רציפה גדולה יכולה להיראות מרשימה בעוד שהיא אומרת מעט על ההשהיה שחווה שירות המבצע קריאות אקראיות קטנות.
NVMe תוכנן עבור מדיה לא נדיפה ו-I/O מקבילי יעיל, אך שם הפרוטוקול שלו אינו מתאר כל חלק בנתיב אחסון מתארח. וירטואליזציה, מערכת הקבצים, תחרות על משאבים והאפליקציה עדיין חשובים. כתבו השערת בדיקה כגון האם השהיית האחסון מאטה פעולה מסוימת, במקום לנסות להפיק מספר שמוכיח שכל השרת מהיר.
תאר את עומס העבודה במונחים ניתנים לשחזור
תעדו את גודל הפעולה, דפוס רציף או אקראי, תערובת קריאה-כתיבה, מספר המשימות ועומק התור. כללו את גודל מערך הנתונים ומשך הבדיקה. תיעוד fio מסביר את בקרות עומס העבודה הללו ואת מנועי ה-I/O הזמינים. עומק מיועד עשוי שלא להיות מושג על ידי כל מנוע או הגדרה, לכן קראו גם את ההתנהגות המדווחת וגם את התצורה שביקשתם.
שמרו עותק של תיאור הבדיקה לצד התוצאה. ציינו את מערכת ההפעלה, מערכת הקבצים, אפשרויות ה-mount, פעילות השירות והקיבולת הזמינה. אם אתם משווים תצורות, שנו תנאי רלוונטי אחד בכל פעם. בדיקה עם דפוס גישה או מקביליות שונים אינה יכולה להיות מוצגת בצדק כאילו רק מדיית האחסון השתנתה.
| דפוס האפליקציה | ממד בדיקה לתיאור | תוצאה לבדיקה |
|---|---|---|
| מסירת קובץ גדול | קריאות רציפות ולקוחות במקביל | תפוקה מתמשכת ושימוש ב-CPU |
| חיפוש רשומה | קריאות אקראיות קטנות ומקביליות מייצגת | התפלגות השהיה ופעולות שהושלמו |
| עסקה עמידה | דרישות כתיבה וסנכרון | השהיה הקשורה לקומיט, לא מהירות כתיבה עם חוצץ בלבד |
| בנייה או חילוץ | פעולות מעורבות של קבצים קטנים | משך משימה מקצה לקצה והמתנות I/O |
שלוט במטמון בלי להעמיד פנים שהוא לא משנה
מערך נתונים שנכנס לזיכרון עשוי למדוד בעיקר התנהגות מטמון לאחר המעבר הראשון. זה יכול להיות שימושי אם האפליקציה נהנית בדרך כלל מאותו מטמון, אך אין לתייג זאת כביצועי התקן גולמיים. בחרו במכוון אם הבדיקה בוחנת נתיב אפליקציה חם, מערך נתונים קר יותר או מצב I/O שנועד להפחית את השפעת החוצץ של מערכת ההפעלה.
תמיכת Direct-I/O ויישור תלויים בפלטפורמה ובמנוע. זה גם אינו מבטא אוטומטית את דרישות העמידות של האפליקציה או מבטל כל מטמון במחסנית. הצהירו בבירור על המצב הנבחר, והימנעו מהשוואת בדיקה עם חוצץ לבדיקה ללא חוצץ כאילו ייצגו את אותה עבודה. הפרידו בין חימום למרווחי מדידה כשזה עוזר לפרשנות.
קרא את זנבות השהיה לצד תפוקה
השהיה ממוצעת יכולה להסתיר פעולות איטיות שמשפיעות על בקשות אמיתיות. בחנו את האחוזונים המדווחים ואת מספר הדגימות שמאחוריהם. אחוזון גבוה מתאר את הגבול שמתחתיו נפלה חלק מוצהר מהפעולות שנצפו במהלך אותה בדיקה; זו אינה הבטחת שירות קבועה. הרצות קצרות או לא מייצגות מספקות ראיות מוגבלות לגבי תקופות ייצור עמוסות.
עומק תור גבוה יותר יכול לשפר תפוקה שהושלמה תוך הגדלת זמן ההמתנה. פשרה זו עשויה להתאים לעיבוד אצווה ולהזיק לשירות אינטראקטיבי. השוו תוצאות במקביליות שדומה לאפליקציה, ונטרו CPU ולחץ I/O בו-זמנית. עצרו לפני שהבדיקה יוצרת הפרעה מיותרת לעומס עבודה אחר שחולק את הסביבה.
שמור על הבדיקה מורשית ולא הרסנית
השתמשו בספריית בדיקה ייעודית או בכרך חד-פעמי מוכן, עם מספיק מקום פנוי ותוכנית ניקוי מפורשת. לעולם אל תכוונו בנצ'מרק כתיבה להתקן גולמי לא מאומת או למערך נתונים בייצור. בדקו את היעד והתנהגות הכתיבה של הכלי לפני ההתחלה, והתחילו בהרצה מוגבלת. I/O סינתטי יכול לצרוך קיבולת ולהפריע לשירותים גם כשהוא אינו דורס קבצים שימושיים.
להערכה דמוית ייצור, סכמו חלון תחזוקה ושמרו על ניטור האפליקציה. השתמשו בנתונים מומצאים כשאפשר. אל תסיקו אמינות אחסון מבדיקת מהירות: בדיקות שלמות, גיבויים ושחזורים הם משימות נפרדות. התקן שמשלים בנצ'מרק עדיין זקוק לאסטרטגיית שחזור למחיקה, טעויות תוכנה או אובדן המכונה.
סגור את המעגל עם ראיות מהאפליקציה
נניח ששירות דוחות מבלה חלק ניכר מזמנו בהמתנה לקריאות אקראיות. הצוות בודק דפוס קריאה מייצג, ואז חוזר על הדוח בפועל מול נתונים דומים. אם הדוח משתפר בעוד שאר עבודתו נשארת יציבה, התוצאה תומכת בהשערת האחסון. אם לא, חקרו עיצוב שאילתות, זיכרון או תלות אחרת במקום לחזור על בדיקות סינתטיות רחבות יותר.
Pulse NVMe ותצורות ייעודיות נבחרות מפרטות אחסון NVMe בקטלוג SwissOctet. התוויות שלהן הן מפרטים, לא בנצ'מרקים שפורסמו לאפליקציות. השתמשו בשיטה מבוקרת כדי להעריך את הסביבה המסופקת ושמרו את התנאים עם הממצאים. ההחלטה מתחזקת כשמדידת האחסון והתוצאה הנראית למשתמש עונות על אותה שאלה.
רשימת הבדיקה המעשית שלך.
- הגדירו תחילה את שאלת האפליקציה.
- תעדו דפוס, גודל בלוק, מקביליות ומשך.
- הצהירו על הנחות מטמון ומצב I/O.
- בחנו אחוזוני השהיה וגם תפוקה.
- השתמשו ביעד חד-פעמי מאומת ובעומס התחלתי מוגבל.
- אמתו את הממצא עם בדיקת אפליקציה.
הפרטים שחשובים.
האם העתקה רציפה מספיקה להשוואת אחסון מסד נתונים?+
בדרך כלל לא. גישה למסד נתונים עשויה לכלול קריאות אקראיות קטנות, כתיבות וסנכרון. מדלו את הדפוס הרלוונטי ואמתו את האפליקציה בפועל.
האם Direct I/O מוכיח כתיבות עמידות?+
לא. חוצץ ועמידות הם עניינים נפרדים. התאימו את התנהגות הסנכרון הנדרשת על ידי האפליקציה.
האם אני יכול לפרסם בדיקה אחת כמהירות מובטחת של התוכנית?+
לא. פרסמו את התנאים וההיקף שלה. תוצאה נמדדת מהרצה אחת אינה הבטחת רמת שירות או ביצועים עתידיים.
לך למקור.
הפניות אלה תומכות במושגים הטכניים במדריך זה. עקוב אחר התיעוד העדכני לפני שינוי מערכת ייצור.
- fio: תיעוד בודק I/O גמיש fio.readthedocs.io
- NVM Express: סקירת מפרט ושאלות נפוצות nvmexpress.org
- ליבת Linux: Pressure Stall Information docs.kernel.org
הדרכה עריכתית מאת SwissOctet. הדוגמאות להמחשה. יש לאמת בנפרד מפרטי שירות, אפשרויות זמינות ותנאים חוזיים.