דיסקים מתמידים מספקים את הביצועים שמתוארים בתרשים סוגי הדיסקים אם השימוש בכוננים של מכונת Compute Engine מספיק כדי להגיע למגבלות הביצועים. אחרי שמשנים את הגודל של נפחי ה-Persistent Disk כדי לעמוד בדרישות הביצועים, יכול להיות שיהיה צורך לבצע התאמות בעומס העבודה ובמערכת ההפעלה.
בקטעים הבאים מתוארים מאפיינים של מכונות וירטואליות ועומסי עבודה שמשפיעים על ביצועי הדיסק, ומוסבר על כמה רכיבים מרכזיים שאפשר לשנות כדי לשפר את הביצועים. חלק מההצעות ואיך ליישם חלק מהן על סוגים ספציפיים של עומסי עבודה.
גורמים שמשפיעים על ביצועי הדיסק
בקטעים הבאים מתוארים גורמים שמשפיעים על הביצועים של דיסק במכונת חישוב.
- מגבלות על תפוקת הכתיבה של תעבורת נתונים יוצאת (egress) ברשת
- קריאה וכתיבה בו-זמנית
- גודל נפח לוגי
- כמה דיסקים שמצורפים למופע חישוב יחיד
מגבלות על תעבורת נתונים יוצאת (egress) ברשת בנפח העברת נתונים בכתיבה
למופע שלכם ב-Compute יש מגבלה על תעבורת נתונים יוצאת מהרשת, שתלויה בסוג המכונה של המופע.
Compute Engine מאחסן נתונים בדיסק אחסון מתמיד עם כמה פעולות כתיבה מקבילות כדי להבטיח יתירות מובנית. בנוסף, לכל בקשת כתיבה יש תקורה שצורכת רוחב פס נוסף לכתיבה.
נפח תנועת הכתיבה המקסימלי שמופע חישוב יכול להנפיק הוא מכסת היציאה מהרשת חלקי מכפיל רוחב פס שמתחשב בשכפול ובתקורה.
הגבלות על תעבורת נתונים יוצאת מהרשת מפורטות בעמודה Default egress bandwidth (Gbps) בטבלאות של סוגי המכונות עבור משפחות המכונות general purpose, compute-optimized, storage-optimized, memory-optimized ו-accelerator-optimized.
מכפיל רוחב הפס הוא בערך פי 1.16 בשימוש מלא ברשת, כלומר 16% מהבייטים שנכתבים הם תקורה. בדיסקים לאחסון מתמיד אזורי, מכפיל רוחב הפס הוא בערך פי 2.32, כדי לפצות על תקורה נוספת של שכפול.
במצב שבו פעולות קריאה וכתיבה של Persistent Disk מתחרות עם רוחב הפס של תעבורת נתונים יוצאת (egress) של הרשת, 60% מרוחב הפס המקסימלי של תעבורת נתונים יוצאת (egress) של הרשת, שמוגדר לפי סוג המכונה, מוקצים לכתיבה של Persistent Disk. 40% הנותרים זמינים לכל שאר תעבורת הנתונים היוצאת מהרשת. פרטים על תעבורה יוצאת אחרת מהרשת זמינים במאמר בנושא רוחב פס יוצא.
בדוגמה הבאה אפשר לראות איך לחשב את רוחב הפס המקסימלי לכתיבה של מכונת וירטואלית מסוג N1 עם דיסק מתמשך. הקצאת רוחב הפס היא החלק מרוחב הפס של תעבורת הנתונים היוצאת מהרשת שהוקצה ל-Persistent Disk. רוחב הפס המקסימלי לכתיבה הוא רוחב הפס המקסימלי לכתיבה של הדיסק הקשיח הקבוע, אחרי התאמה לתקורה.
| מספר מעבדים וירטואליים | מגבלת תעבורת נתונים יוצאת (egress) ברשת (MB/s) | הקצאת רוחב פס (MB לשנייה) | רוחב פס מקסימלי לכתיבה (MB/s) | רוחב הפס המקסימלי לכתיבה בניצול מלא של הרשת (MB/s) |
|---|---|---|---|---|
| 1 | 250 | 150 | 216 | 129 |
| 2-7 | 1,250 | 750 | 1,078 | 647 |
| 8-15 | 2,000 | 1,200 | 1,724 | 1,034 |
| 16+ | 4,000 | 2,400 | 3,448 | 2,069 |
אפשר לחשב את רוחב הפס המקסימלי של Persistent Disk באמצעות הנוסחאות הבאות:
מכונת N1 עם vCPU אחד
הגבלת התעבורה היוצאת מהרשת היא:
2Gbps / 8 bits = 0.25GB לשנייה = 250MB לשנייה
הקצאת רוחב הפס של הדיסק של האחסון המתמיד (persistent disk) בשימוש מלא ברשת היא:
250MB לשנייה * 0.6 = 150MB לשנייה.
רוחב הפס המקסימלי לכתיבה ב-Persistent Disk ללא התנגשות ברשת הוא:
- דיסקים אזוריים: 250MB לשנייה חלקי 1.16 ~= 216MB לשנייה
- דיסקים אזוריים: 250MB לשנייה חלקי 2.32 ~= 108MB לשנייה
רוחב הפס המקסימלי לכתיבה ב-Persistent Disk בשימוש מלא ברשת הוא:
- דיסקים אזוריים: 150MB לשנייה חלקי 1.16 שווה בערך 129MB לשנייה
- דיסקים אזוריים: 150MB לשנייה חלקי 2.32 שווה בערך 65MB לשנייה
מגבלות היציאה מהרשת מספקות רף עליון לביצועים. גורמים אחרים עשויים להגביל את הביצועים מתחת לרמה הזו. בקטעים הבאים מופיע מידע על מגבלות אחרות שקשורות לביצועים.
קריאה וכתיבה בו-זמנית
בדיסק מתמיד סטנדרטי, קריאות וכתיבות בו-זמניות חולקות את אותם משאבים. כשמופע המחשוב משתמש ביותר נתונים לקריאה או IOPS, הוא יכול לבצע פחות פעולות כתיבה. לעומת זאת, מקרים שבהם נעשה שימוש בנפח העברת נתונים גדול יותר לכתיבה או ב-IOPS, יכולים לבצע פחות קריאות.
אי אפשר להגיע בו-זמנית למגבלות של נפח התפוקה ושל פעולות הקלט/פלט בשני הכיוונים (קריאה וכתיבה) בכרטיסי Persistent Disk.
החישוב של קצב העברת הנתונים הוא IOPS * I/O size. כדי לנצל את מגבלות התפוקה המקסימליות לקריאה וכתיבה בו-זמניות ב-SSD Persistent Disk, צריך להשתמש בגודל קלט/פלט כך שסך ה-IOPS של הקריאה והכתיבה לא יעלה על מגבלת ה-IOPS.
בטבלה הבאה מפורטות מגבלות ה-IOPS לכל מכונת חישוב לקריאות וכתיבות בו-זמניות.
| דיסק מתמיד סטנדרטי | דיסק מתמיד שמבוסס על SSD (8 ליבות vCPU) | דיסק מתמיד שמבוסס על SSD (32 vCPU ומעלה) | דיסק מתמיד שמבוסס על SSD (64 vCPU ומעלה) | ||||
|---|---|---|---|---|---|---|---|
| קריאה | כתיבה | קריאה | כתיבה | קריאה | כתיבה | קריאה | כתיבה |
| 7,500 | 0 | 15,000 | 0 | 60,000 | 0 | 100,000 | 0 |
| 5,625 | 3,750 | 11,250 | 3,750 | 45,000 | 15,000 | 75,000 | 25,000 |
| 3,750 | 7,500 | 7,500 | 7,500 | 30,000 | 30,000 | 50,000 | 50,000 |
| 1875 | 11,250 | 3,750 | 11,250 | 15,000 | 45,000 | 25,000 | 75,000 |
| 0 | 15,000 | 0 | 15,000 | 0 | 60,000 | 0 | 100,000 |
מספרי ה-IOPS בטבלה הזו מבוססים על גודל קלט/פלט של 8 KB. יכול להיות שלגודלי קלט/פלט אחרים, כמו 16 KB, יהיו ערכי IOPS שונים, אבל הם ישמרו על אותה חלוקה של קריאה וכתיבה.
בטבלה הבאה מפורטות מגבלות התפוקה (MiB לשנייה) לכל מופע לקריאות וכתיבות בו-זמניות.
| דיסק מתמיד סטנדרטי | דיסק מתמיד שמבוסס על SSD (6 עד 14 ליבות vCPU) | דיסק מתמיד שמבוסס על SSD (16 vCPU ומעלה) | |||
|---|---|---|---|---|---|
| קריאה | כתיבה | קריאה | כתיבה | קריאה | כתיבה |
| 1200 | 0 | 800* | 800* | 1,200* | 1,200* |
| 900 | 100 | ||||
| 600 | 200 | ||||
| 300 | 300 | ||||
| 0 | 400 | ||||
גודל נפח אחסון לוגי
גודל של Persistent Disk יכול להגיע עד 64 TiB, ואפשר ליצור נפחים לוגיים יחידים בגודל של עד 257 TiB באמצעות ניהול נפחים לוגיים בתוך מכונת החישוב. גודל נפח גדול יותר משפיע על הביצועים בדרכים הבאות:
- לא כל מערכות הקבצים המקומיות פועלות טוב בקנה מידה כזה. יכול להיות שפעולות נפוצות, כמו טעינה ובדיקה של מערכת הקבצים, יימשכו יותר זמן מהצפוי.
- הביצועים המקסימליים של דיסק מתמשך מושגים בגדלים קטנים יותר. הזמן שנדרש לקריאה או לכתיבה מלאה בדיסקים ארוך יותר כשיש כל כך הרבה נפח אחסון במופע אחד של Compute. אם האפליקציה שלכם תומכת בכך, כדאי להשתמש בכמה מכונות וירטואליות כדי להגדיל את התפוקה הכוללת של המערכת.
- יכול להיות שיצירת תמונת מצב של מספרים גדולים של Persistent Disk תימשך יותר זמן מהצפוי, ויכול להיות שהיא תספק תצוגה לא עקבית של הנפח הלוגי שלכם אם לא תתבצע תיאום מדויק עם האפליקציה.
כמה דיסקים שמצורפים למופע חישוב יחיד
מגבלות הביצועים של דיסקים כשמחוברים כמה דיסקים למופע חישוב תלויות בסוג הדיסקים – אם הם מאותו סוג או מסוגים שונים.
כמה דיסקים מאותו סוג
אם יש לכם כמה דיסקים מאותו סוג שמצורפים למופע של מכונת חישוב באותו מצב (לדוגמה, קריאה/כתיבה), מגבלות הביצועים זהות למגבלות של דיסק יחיד בגודל משולב של הדיסקים האלה. אם משתמשים בכל הדיסקים ב-100%, מגבלת הביצועים הכוללת מתחלקת באופן שווה בין הדיסקים, בלי קשר לגודל היחסי של הדיסקים.
לדוגמה, נניח שיש לכם דיסק pd-standard בנפח 200GB ודיסק pd-standard בנפח 1,000GB. אם לא משתמשים בדיסק בנפח 1,000GB, הדיסק בנפח 200GB יכול להגיע למגבלת הביצועים של דיסק סטנדרטי בנפח 1,200GB. אם משתמשים בשני הדיסקים ב-100%, לכל אחד מהם יש מגבלת ביצועים של דיסק בנפח
600GBpd-standard (1,200GB חלקי 2 דיסקים = דיסק בנפח 600GB).
כמה דיסקים מסוגים שונים
אם מצרפים סוגים שונים של דיסקים למופע Compute, הביצועים המקסימליים האפשריים הם מגבלת הביצועים של הדיסק המהיר ביותר שהמופע Compute תומך בו. הביצועים המצטברים של הדיסקים המצורפים לא יעלו על מגבלות הביצועים של הדיסק המהיר ביותר שמופע המחשוב תומך בו.
אופטימיזציה של הדיסקים לעומסי עבודה שמתמקדים ב-IOPS או בתפוקה
ההמלצות לשיפור הביצועים תלויות בבחירה שלכם בין מיקסום של IOPS לבין מיקסום של קצב העברת הנתונים.
עומסי עבודה שמתמקדים ב-IOPS
במסדי נתונים, בין אם הם מסוג SQL או NoSQL, יש דפוסי שימוש של גישה אקראית לנתונים. Google ממליצה על הערכים הבאים לעומסי עבודה שמתמקדים ב-IOPS:
ערכי עומק של תור קלט/פלט של 1 לכל 400 עד 800 IOPS, עד למגבלה של 64 בכרכים גדולים
מעבד אחד בחינם לכל 2,000 פעולות קלט/פלט של קריאה אקראית, ומעבד אחד בחינם לכל 2,500 פעולות קלט/פלט של כתיבה אקראית
אם סוג המכונה של מופע החישוב תומך בהם, כדאי להשתמש בדיסקים מסוג Hyperdisk Extreme או Hyperdisk Balanced, שמאפשרים לשנות את ה-IOPS שהוקצו.
בדרך כלל, במסמכים עם שיטות מומלצות ל-MongoDB, ל-Apache Cassandra וליישומים אחרים של מסדי נתונים, מומלץ להשתמש בערכים נמוכים יותר של קריאה מראש.
עומסי עבודה שמתמקדים בנפח הנתונים
פעולות סטרימינג, כמו משימת Hadoop, נהנות מקריאות רציפות מהירות, וגדלים גדולים יותר של קלט/פלט יכולים לשפר את ביצועי הסטרימינג.
צריך להשתמש בגודל קלט/פלט של 256KB או יותר.
אם סוג המכונה של מופע Compute תומך בהם, כדאי להשתמש בדיסקים מסוג Hyperdisk Throughput או Hyperdisk Balanced, שמאפשרים לשנות את רוחב הפס שהוקצה.
בדיסק מתמיד סטנדרטי, מומלץ להשתמש ב-8 או יותר זרמי קלט/פלט מקבילים רציפים, אם אפשר. דיסק מתמיד סטנדרטי נועד לבצע אופטימיזציה של ביצועי קלט/פלט (I/O) לגישה רציפה לדיסק, בדומה לכונן קשיח פיזי (HDD).
חשוב לוודא שהאפליקציה מותאמת ללוקאליות סבירה של נתונים בדיסקים גדולים.
אם האפליקציה שלכם ניגשת לנתונים שמפוזרים בחלקים שונים של דיסק במשך תקופה קצרה (מאות GB לכל vCPU), לא תשיגו IOPS אופטימלי. כדי להשיג את הביצועים הטובים ביותר, כדאי לבצע אופטימיזציה של מיקום הנתונים, תוך התחשבות בגורמים כמו הפיצול של הדיסק והאקראיות של החלקים בדיסק שאליהם מתבצעת גישה.
במקרה של דיסק מתמיד שמבוסס על SSD, צריך לוודא שתזמון הקלט/פלט במערכת ההפעלה מוגדר בהתאם לצרכים הספציפיים שלכם.
במערכות מבוססות Linux, בודקים אם מתזמן הקלט/פלט מוגדר ל-
none. מתזמן הקלט/פלט הזה לא מסדר מחדש את הבקשות, והוא מתאים במיוחד למכשירי קלט/פלט מהירים ואקראיים.בודקים בשורת הפקודה את לוח הזמנים של קלט/פלט שבו משתמש מחשב Linux:
cat /sys/block/sda/queue/scheduler
הפלט אמור להיראות כך:
[mq-deadline] none
מתזמן הקלט/פלט שפעיל כרגע מוצג בסוגריים מרובעים (
[]).אם מתזמן הקלט/פלט לא מוגדר ל-
none, מבצעים אחת מהפעולות הבאות:- כדי לשנות את מתזמן הקלט/פלט שמוגדר כברירת מחדל ל-
none, מגדירים אתelevator=noneברשומהGRUB_CMDLINE_LINUXשל קובץ ההגדרות של GRUB. בדרך כלל הקובץ הזה נמצא ב-/etc/default/grub, אבל בחלק מההפצות הקודמות הוא נמצא בספרייה אחרת.
GRUB_CMDLINE_LINUX="elevator=none vconsole.keymap=us console=ttyS0,38400n8 vconsole.font=latarcyrheb-sun16
אחרי שמעדכנים את קובץ ההגדרות של GRUB, צריך להגדיר את טוען האתחול במערכת כדי שהיא תוכל לבצע אתחול ב-Compute Engine.
- אפשרות אחרת היא לשנות את מתזמן הקלט/פלט בזמן הריצה:
echo 'none' | sudo tee /sys/block/sda/queue/scheduler
אם משתמשים בשיטה הזו, המערכת חוזרת לשימוש בתזמון ברירת המחדל של קלט/פלט בהפעלה מחדש. מריצים שוב את הפקודה
catכדי לאמת את מתזמן הקלט/פלט.- כדי לשנות את מתזמן הקלט/פלט שמוגדר כברירת מחדל ל-
שינויים בעומס העבודה שיכולים לשפר את ביצועי הדיסק
התנהגויות מסוימות של עומסי עבודה יכולות לשפר את הביצועים של פעולות קלט/פלט בדיסקים המצורפים.
שימוש בעומק תור גבוה של קלט/פלט
זמן האחזור של Persistent Disks גבוה יותר מזה של דיסקים שמצורפים באופן מקומי, כמו דיסקים של Local SSD, כי הם מכשירים שמצורפים לרשת. הם יכולים לספק IOPS וקצב העברה גבוהים מאוד, אבל צריך לוודא שמבצעים מספיק בקשות קלט/פלט במקביל. מספר בקשות הקלט/פלט שמתבצעות במקביל נקרא עומק תור הקלט/פלט.
בטבלאות הבאות מפורטת עומק התור המומלץ של קלט/פלט כדי להבטיח שתוכלו להשיג רמת ביצועים מסוימת. הטבלאות מציגות הערכת יתר קלה של זמן האחזור האופייני כדי להציג המלצות שמרניות. בדוגמה מניחים שגודל הקלט/פלט הוא 16KB.
יצירת מספיק פעולות קלט/פלט באמצעות גודל גדול של פעולות קלט/פלט
שימוש בגודל גדול של קלט/פלט
כדי לוודא שמגבלות ה-IOPS וזמן האחזור לא יפגעו בביצועים של האפליקציה, צריך להשתמש בגודל קלט/פלט מינימלי של 256KB או יותר.
מומלץ להשתמש בגדלים גדולים של פסים באפליקציות של מערכת קבצים מבוזרת. עומס עבודה אקראי של קלט/פלט עם גדלים גדולים של פס (4MB או יותר) משיג ביצועים מצוינים בדיסק מתמיד סטנדרטי, כי עומס העבודה דומה מאוד לגישה לדיסק של כמה זרמים רציפים.
מוודאים שהאפליקציה מייצרת מספיק פעולות קלט/פלט
צריך לוודא שהאפליקציה יוצרת מספיק פעולות קלט/פלט כדי להשתמש במלוא המגבלות של IOPS ושל קצב העברת הנתונים של הדיסק. כדי להבין טוב יותר את דפוס הקלט/פלט של עומס העבודה, כדאי לבדוק את השימוש בדיסק ואת מדדי הביצועים ב-Cloud Monitoring.
מוודאים שיש מספיק מעבד פנוי במופע שמייצר את קלט/פלט
אם יש מחסור במעבד במופע החישוב, האפליקציה לא תוכל לנהל את פעולות הקלט/פלט שמתוארות למעלה. מומלץ להקצות מעבד אחד לכל 2,000 עד 2,500 פעולות קלט/פלט בשנייה של תנועה צפויה.
הגבלת עומסי קלט/פלט כבדים לטווח מקסימלי
טווח (span) מתייחס לטווח רציף של כתובות בלוק לוגיות בדיסק פיזי יחיד. עומסי קלט/פלט כבדים משיגים ביצועים מקסימליים כשהם מוגבלים לטווח מקסימלי מסוים, שתלוי בסוג המכונה של מופע המחשוב שאליו הדיסק מצורף, כפי שמפורט בטבלה הבאה.
| סוג המכונה | טווח מקסימלי מומלץ |
|---|---|
|
25TB |
| כל שאר סוגי המכונות | 50TB |
אם יש לכם טווחי כתובות בנפרד ב-Persistent Disks, והגודל הכולל שלהם הוא עד 50TB, אפשר להתייחס אליהם כאל טווח כתובות אחד של 50TB לצורך ביצועים.
שינויים במערכת ההפעלה כדי לשפר את ביצועי הדיסק
במקרים מסוימים, אפשר להפעיל או להשבית תכונות ברמת מערכת ההפעלה, או להגדיר את הדיסקים המצורפים בדרכים ספציפיות כדי לשפר את הביצועים של הדיסק.
הימנעות משימוש במערכות קבצים של ext3 ב-Linux
שימוש במערכת הקבצים ext3 במופע מחשוב של Linux עלול לגרום לביצועים ירודים מאוד בעומסי כתיבה כבדים. כדאי להשתמש ב-ext4 כשזה אפשרי. מנהל ההתקן של מערכת הקבצים ext4 תואם לאחור ל-ext3 ול-ext2, ותומך בטעינה של מערכות קבצים מסוג ext3. מערכת הקבצים ext4 היא ברירת המחדל ברוב מערכות ההפעלה של Linux.
אם אי אפשר לבצע מיגרציה אל ext4, אפשר לטעון מערכות קבצים של ext3 באמצעות האפשרות data=journal mount. הפעולה הזו משפרת את קצב ה-IOPS של הכתיבה, אבל פוגעת בנפח הנתונים של הכתיבה. המעבר אל ext4 יכול להוביל לשיפור של עד פי 7 בחלק מהשווקים.
השבתת אתחול מדורג והפעלת פקודות DISCARD
כוננים קשיחים קבועים תומכים בפעולות השמדה או בפקודות TRIM, שמאפשרות למערכות הפעלה להודיע לכוננים כשבלוקים כבר לא בשימוש. תמיכה בהסרה מאפשרת למערכת ההפעלה לסמן בלוקים בדיסק כבלוקים שכבר לא נדרשים, בלי לשלם את העלות של איפוס הבלוקים.
ברוב מערכות ההפעלה של Linux, מפעילים פעולות של ביטול שינויים כשמצמידים דיסק מתמשך למופע של Compute. במקרים של מכונות וירטואליות של Windows Server 2012 R2, פעולות ביטול מופעלות כברירת מחדל כשמפעילים דיסק קבוע.
הפעלת פעולות השמטה יכולה לשפר את הביצועים הכלליים של זמן הריצה, ויכולה גם להאיץ את הביצועים של הדיסק כשמצמידים אותו בפעם הראשונה. פירמוט של נפח דיסק שלם יכול להיות תהליך ארוך, ולכן פירמוט עצלני הוא שיטה נפוצה. החיסרון בפורמט העצלני הוא שהעלות משולמת בדרך כלל בפעם הראשונה שבה הכרך מותקן. אם משביתים את האתחול העצלן ומפעילים את פעולות ההסרה, אפשר לבצע פעולות מהירות של עיצוב והרכבה.
כדי להשבית את האתחול העצלן ולהפעיל פעולות ביטול כשמעצבים דיסק, מעבירים את הפרמטרים הבאים אל mkfs.ext4:
-E lazy_itable_init=0,lazy_journal_init=0,discardהפרמטר
lazy_journal_init=0לא פועל במופעים עם תמונות של CentOS 6 או RHEL 6. במקרים של מכונות וירטואליות שמשתמשות במערכות ההפעלה האלה, צריך לעצב את הדיסק לאחסון מתמיד בלי הפרמטר הזה.-E lazy_itable_init=0,discardכדי להפעיל פעולות של ביטול שינויים כשמטעינים דיסק, מעבירים את הדגל הבא לפקודה
mount:-o discard
השימוש ב-Persistent Disk מומלץ כשהאפשרות 'ביטול' מופעלת. עם זאת, אפשר להפעיל את fstrim מעת לעת בנוסף לפעולות של ביטול שינויים, או במקום להשתמש בהן. אם אתם לא משתמשים בפעולות ביטול, אתם צריכים להריץ את הפקודה fstrim לפני שאתם יוצרים snapshot של דיסק האתחול. חיתוך של מערכת הקבצים מאפשר ליצור תמונות מצב קטנות יותר, וכך להפחית את העלות של אחסון תמונות מצב.
שינוי הערך של קריאה מראש
כדי לשפר את ביצועי הקלט/פלט, מערכות הפעלה משתמשות בטכניקות כמו readahead, שבה קובץ נקרא לזיכרון בהיקף גדול יותר ממה שהתבקש, מתוך הנחה שקריאות עוקבות כנראה יזדקקו לנתונים האלה. הגדלה של קריאה מראש משפרת את קצב העברת הנתונים, אבל פוגעת בזיכרון וב-IOPS. הפחתה של קריאה מראש מגדילה את מספר פעולות הקלט/פלט בשנייה (IOPS) על חשבון התפוקה.
במערכות Linux, אפשר לקבל ולהגדיר את ערך הקריאה מראש באמצעות הפקודה blockdev:
$ sudo blockdev --getra /dev/DEVICE_ID
$ sudo blockdev --setra VALUE /dev/DEVICE_ID
ערך הקריאה מראש הוא <desired_readahead_bytes> / 512 בייטים.
לדוגמה, אם הגודל של הקריאה מראש הוא 8 MB, הערך הוא 8388608 בייטים (8 * 1024 * 1024).
8388608 bytes / 512 bytes = 16384
הגדרתם את blockdev ל-16384:
$ sudo blockdev --setra 16384 /dev/DEVICE_ID
שימוש בגודל סקטור של 4KB עבור xfs
כשמפרמטים דיסק באמצעות xfs, גודל הסקטור שמוגדר כברירת מחדל הוא 512 בייטים. כדי להימנע מתקורה של קריאה-שינוי-כתיבה ולשפר את הביצועים, צריך לפרמט את הדיסק עם גודל סקטור של 4 KB:
$ sudo mkfs.xfs -s size=4096 /dev/DEVICE_NAME
מחליפים את DEVICE_NAME בשם המכשיר של הדיסק שאתם מפרמטים. לדוגמה, sdb.
לשנות את מכונת החישוב או ליצור מכונה חדשה
יש מגבלות שמשויכות לכל סוג מכונה, והן יכולות להשפיע על הביצועים שאפשר לקבל מהדיסקים המצורפים. המגבלות האלה כוללות:
- הביצועים של דיסק אחסון מתמיד משתפרים ככל שמספר יחידות ה-vCPU הזמינות גדל.
- לא כל סוגי המכונות תומכים ב-Hyperdisk.
- שיעורי התעבורה היוצאת מהרשת עולים ככל שמספר המעבדים הווירטואליים הזמינים עולה.
מוודאים שיש מעבדים פנויים
קריאה וכתיבה של נפחי Persistent Disk דורשות מחזורי CPU ממופע המחשוב. כדי להגיע לרמות גבוהות מאוד ועקביות של IOPS, צריך לוודא שיש מעבדים פנויים לעיבוד קלט/פלט.
כדי להגדיל את מספר יחידות ה-vCPU שזמינות למופע של Compute, אפשר ליצור מופע חדש של Compute או לערוך את סוג המכונה של מופע של Compute.
כדאי להשתמש ב-Google Cloud Hyperdisk
כדי לקבל IOPS וקצב העברת נתונים גבוהים יותר, כדאי להשתמש בדיסקים מסוג Hyperdisk במקום בדיסקים לאחסון מתמיד, אם סדרת המכונות שלכם תומכת ב-Hyperdisk.
כדי לבדוק אם סדרת המכונות שלכם תומכת ב-Hyperdisk, אפשר לעיין במאמר בנושא תמיכה בסדרות מכונות ב-Hyperdisk.
אם סדרת המכונות של המופע תומכת ב-Hyperdisk, פועלים לפי השלבים הבאים כדי להשתמש באמצעי אחסון מסוג Hyperdisk:
בוחרים סוג Hyperdisk שמתאים לצרכים של עומס העבודה.
כדי לעבור לסוג ה-Hyperdisk שבחרתם, אפשר לעיין בהוראות שבמאמר שינוי סוג הדיסק.
שינוי סדרת המכונות של המופע כדי לשפר את הביצועים
סדרות מכונות מהדורות האחרונים פועלות בדרך כלל במעבדים חדשים יותר, שיכולים להציע ביצועים טובים יותר מהדורות הקודמים. בנוסף, מעבדים חדשים יותר יכולים לתמוך בפונקציונליות נוספת כדי לשפר את הביצועים של עומסי העבודה, כמו Advanced Matrix Extensions (AMX) או Intel Advanced Vector Extensions (AVX-512).
המאמרים הבאים
- כדי לעקוב אחרי הביצועים של הדיסק, אפשר לבדוק את מדדי הביצועים של הדיסק ולעקוב אחרי תקינות הדיסק.
- נפחי Persistent Disk של בדיקת ביצועים שמצורפים אל:
- מידע על התמחור של Persistent Disk
- איך בודקים את מדדי הביצועים של הדיסק