דיסקים אחסון מתמיד (persistent disk) מספקים את הביצועים שמתוארים בתרשים סוגי הדיסקים אם השימוש במכונת ה-VM מספיק כדי להגיע למגבלות הביצועים. אחרי שקובעים את הגודל של נפחי ה-Persistent Disk בהתאם לצרכי הביצועים, יכול להיות שיהיה צורך לבצע התאמות בעומס העבודה ובמערכת ההפעלה.
בקטעים הבאים מתוארים מאפיינים של מכונות וירטואליות ועומסי עבודה שמשפיעים על הביצועים של הדיסק, ומוסברים כמה רכיבים מרכזיים שאפשר לכוונן כדי לשפר את הביצועים. חלק מההצעות ואיך ליישם חלק מהן על סוגים ספציפיים של עומסי עבודה.
גורמים שמשפיעים על ביצועי הדיסק
בקטעים הבאים מתוארים גורמים שמשפיעים על הביצועים של דיסק במכונה וירטואלית.
- מגבלות על תפוקת הכתיבה של תעבורת נתונים יוצאת (egress) ברשת
- קריאה וכתיבה בו-זמנית
- גודל נפח לוגי
- כמה דיסקים שמחוברים למכונה וירטואלית אחת
מגבלות על תפוקת הכתיבה של תעבורת נתונים יוצאת (egress) ברשת
למכונה הווירטואלית יש מגבלה על תעבורת נתונים יוצאת מהרשת, שתלויה בסוג המכונה הווירטואלית.
Compute Engine מאחסן נתונים בדיסק אחסון מתמיד עם כמה פעולות כתיבה מקבילות כדי להבטיח יתירות מובנית. בנוסף, לכל בקשת כתיבה יש תקורה שצורכת רוחב פס נוסף לכתיבה.
תנועת הכתיבה המקסימלית שמכונה וירטואלית יכולה להפיק היא מכסת היציאה מהרשת חלקי מכפיל רוחב פס שמביא בחשבון את השכפול והתקורה.
מגבלות היציאה מהרשת מפורטות בעמודה Default egress bandwidth (Gbps) בטבלאות של סוגי המכונות עבור משפחות המכונות general purpose, compute-optimized, storage-optimized, memory-optimized ו-accelerator-optimized.
מכפיל רוחב הפס הוא בערך 1.16x בניצול מלא של הרשת, כלומר 16% מהבייטים שנכתבים הם תקורה. במקרה של Persistent Disk אזורי, מכפיל רוחב הפס הוא בערך פי 2.32, כדי לפצות על תקורה נוספת של רפליקציה.
במצב שבו פעולות קריאה וכתיבה של Persistent Disk מתחרות עם רוחב הפס של תעבורת נתונים יוצאת (egress) של הרשת, 60% מרוחב הפס המקסימלי של תעבורת נתונים יוצאת (egress) של הרשת, שמוגדר לפי סוג המכונה, מוקצים לכתיבות של Persistent Disk. 40% הנותרים זמינים לכל שאר תעבורת הנתונים היוצאת מהרשת. פרטים על תנועת יציאה אחרת מהרשת זמינים במאמר בנושא רוחב פס של תנועת נתונים יוצאת.
בדוגמה הבאה אפשר לראות איך מחשבים את רוחב הפס המקסימלי לכתיבה עבור Persistent Disk במופע של מכונה וירטואלית N1. הקצאת רוחב הפס היא החלק מרוחב הפס של יציאת הרשת שהוקצה ל-Persistent Disk. רוחב הפס המקסימלי לכתיבה הוא רוחב הפס המקסימלי לכתיבה של ה-Persistent Disk, מותאם לתקורה.
| מספר ליבות ה-vCPU של מכונה וירטואלית | מגבלת תעבורת נתונים יוצאת (egress) ברשת (MB/s) | הקצאת רוחב פס (MB/s) | רוחב פס מקסימלי לכתיבה (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 עם 1 vCPU
הגבלת תעבורת הנתונים היוצאת (egress) מהרשת היא:
2Gbps / 8 bits = 0.25GB per second = 250MB per second
הקצאת רוחב הפס של Persistent Disk בשימוש מלא ברשת היא:
250 MB לשנייה * 0.6 = 150 MB לשנייה.
רוחב הפס המקסימלי לכתיבה ב-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 המקסימליות שלהם גם לקריאה וגם לכתיבה.
החישוב של קצב העברת הנתונים הוא IOPS * I/O size. כדי לנצל את מגבלות התפוקה המקסימליות לקריאה וכתיבה בו-זמניות בדיסק מתמיד שמבוסס על SSD, צריך להשתמש בגודל קלט/פלט כך שקריאה וכתיבה של IOPS ביחד לא יעלו על מגבלת ה-IOPS.
בטבלה הבאה מפורטות מגבלות ה-IOPS לכל מכונה וירטואלית לקריאות וכתיבות בו-זמניות.
| Standard Persistent Disk | דיסק מתמיד שמבוסס על SSD (8 vCPUs) | דיסק מתמיד שמבוסס על SSD (32+ מעבדי vCPU) | דיסק מתמיד שמבוסס על SSD (64+ vCPUs) | ||||
|---|---|---|---|---|---|---|---|
| קריאה | כתיבה | קריאה | כתיבה | קריאה | כתיבה | קריאה | כתיבה |
| 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 לשנייה) לכל מופע עבור קריאות וכתיבות בו-זמניות.
| Standard Persistent Disk | דיסק מתמיד שמבוסס על SSD (6 עד 14 ליבות וירטואליות של CPU) | דיסק מתמיד שמבוסס על SSD (16+ vCPUs) | |||
|---|---|---|---|---|---|
| קריאה | כתיבה | קריאה | כתיבה | קריאה | כתיבה |
| 1200 | 0 | 800* | 800* | 1,200* | 1,200* |
| 900 | 100 | ||||
| 600 | 200 | ||||
| 300 | 300 | ||||
| 0 | 400 | ||||
גודל נפח לוגי
הגודל של דיסק לאחסון מתמיד יכול להגיע עד 64 TiB, ואפשר ליצור נפחים לוגיים יחידים של עד 257 TiB באמצעות ניהול נפחים לוגיים בתוך מכונת ה-VM. גודל נפח גדול יותר משפיע על הביצועים בדרכים הבאות:
- לא כל מערכות הקבצים המקומיות פועלות טוב בקנה מידה כזה. יכול להיות שפעולות נפוצות, כמו טעינה ובדיקה של מערכת הקבצים, יימשכו יותר זמן מהצפוי.
- הביצועים המקסימליים של Persistent Disk מושגים בגדלים קטנים יותר. הזמן שנדרש לקריאה או לכתיבה מלאה בדיסקים ארוך יותר כשיש כל כך הרבה נפח אחסון ב-VM אחד. אם האפליקציה שלכם תומכת בכך, מומלץ להשתמש בכמה מכונות וירטואליות כדי להגדיל את התפוקה הכוללת של המערכת.
- יכול להיות שייקח יותר זמן מהצפוי ליצור תמונת מצב של מספרים גדולים של Persistent Disk, ויכול להיות שתמונת המצב לא תציג תצוגה עקבית של הנפח הלוגי שלכם אם לא תתבצע תיאום מדויק עם האפליקציה.
כמה דיסקים שמצורפים למופע יחיד של מכונה וירטואלית
מגבלות הביצועים של דיסקים כשמצורפים כמה דיסקים למכונה וירטואלית תלויות בסוג הדיסקים.
כמה דיסקים מאותו סוג
אם יש לכם כמה דיסקים מאותו סוג שמצורפים למכונת VM באותו מצב (למשל, קריאה/כתיבה), מגבלות הביצועים זהות למגבלות של דיסק יחיד עם גודל משולב של הדיסקים האלה. אם משתמשים בכל הדיסקים ב-100%, מגבלת הביצועים הכוללת מתחלקת באופן שווה בין הדיסקים, בלי קשר לגודל היחסי של הדיסק.
לדוגמה, נניח שיש לכם דיסק pd-standard בנפח 200GB ודיסק pd-standard בנפח 1,000GB. אם לא משתמשים בדיסק בנפח 1,000GB, הדיסק בנפח 200GB יכול להגיע למגבלת הביצועים של דיסק סטנדרטי בנפח 1,200GB. אם משתמשים בשני הדיסקים ב-100%, לכל אחד מהם יש מגבלת ביצועים של דיסק בנפח 600GB (1,200GB חלקי 2 דיסקים = דיסק בנפח 600GB).pd-standard
כמה דיסקים מסוגים שונים
אם מצרפים סוגים שונים של דיסקים למכונה וירטואלית, הביצועים המקסימליים האפשריים הם מגבלת הביצועים של הדיסק הכי מהיר שהמכונה הווירטואלית תומכת בו. הביצועים המצטברים של הדיסקים המצורפים לא יעלו על מגבלות הביצועים של הדיסק המהיר ביותר שהמכונה הווירטואלית תומכת בו.
אופטימיזציה של הדיסקים לעומסי עבודה שמתמקדים ב-IOPS או בתפוקה
ההמלצות לשיפור הביצועים תלויות בשאלה אם רוצים למקסם את IOPS או את קצב העברת הנתונים.
עומסי עבודה שמתמקדים ב-IOPS
במסדי נתונים, בין אם הם מסוג SQL או NoSQL, יש דפוסי שימוש של גישה אקראית לנתונים. Google ממליצה על הערכים הבאים לעומסי עבודה שמתמקדים ב-IOPS:
ערכי עומק של תור קלט/פלט של 1 לכל 400 עד 800 של IOPS, עד למגבלה של 64 בכרכים גדולים
מעבד אחד בחינם לכל 2,000 פעולות קלט/פלט (IOPS) של קריאה אקראית, ומעבד אחד בחינם לכל 2,500 פעולות קלט/פלט (IOPS) של כתיבה אקראית
אם האפשרות זמינה לסוג המכונה הווירטואלית שלכם, כדאי להשתמש בדיסקים של Google Cloud Hyperdisk Extreme, שמאפשרים לשנות את ה-IOPS שהוקצה.
במסמכים עם שיטות מומלצות ל-MongoDB, ל-Apache Cassandra וליישומים אחרים של מסדי נתונים, בדרך כלל מומלץ להשתמש בערכים נמוכים יותר של קריאה מראש.
עומסי עבודה שמתמקדים בתפוקה
פעולות סטרימינג, כמו משימת Hadoop, נהנות מקריאות רציפות מהירות, וגדלים גדולים יותר של קלט/פלט יכולים לשפר את ביצועי הסטרימינג.
צריך להשתמש בגודל קלט/פלט של 256KB או יותר.
אם האפשרות זמינה לסוג מכונת ה-VM שלכם, כדאי להשתמש בדיסקים מסוג Hyperdisk Throughput, שמאפשרים לשנות את נפח התפוקה שהוקצה.
בדיסק מתמיד סטנדרטי, מומלץ להשתמש ב-8 או יותר זרמי קלט/פלט עוקבים מקבילים, אם אפשר. דיסק מתמיד סטנדרטי מיועד לאופטימיזציה של ביצועי קלט/פלט (I/O) לגישה רציפה לדיסק, בדומה לכונן קשיח פיזי (HDD).
חשוב לוודא שהאפליקציה מותאמת ללוקאליות סבירה של נתונים בדיסקים גדולים.
אם האפליקציה שלכם ניגשת לנתונים שמפוזרים בחלקים שונים של דיסק בפרק זמן קצר (מאות GB לכל vCPU), לא תשיגו IOPS אופטימלי. כדי להשיג את הביצועים הטובים ביותר, כדאי לבצע אופטימיזציה של מיקום הנתונים, תוך התחשבות בגורמים כמו הפיצול של הדיסק והאקראיות של החלקים בדיסק שאליהם מתבצעת גישה.
במקרה של דיסק מתמיד שמבוסס על SSD, צריך לוודא שתזמן קלט/פלט במערכת ההפעלה מוגדר בהתאם לצרכים הספציפיים שלכם.
במערכות מבוססות Linux, בודקים אם מתזמן הקלט/פלט מוגדר ל-
none. מתזמן קלט/פלט (I/O) הזה לא מסדר מחדש בקשות והוא אידיאלי למכשירי קלט/פלט מהירים ואקראיים.בשורה של הפקודה, מאמתים את לוח הזמנים של הקלט/פלט שבו משתמש מחשב Linux:
cat /sys/block/sda/queue/scheduler
הפלט אמור להיראות כך:
[mq-deadline] none
מתזמן הפגישות של I/O שפעיל כרגע מוצג בסוגריים מרובעים (
[]).אם מתזמן הקלט/פלט לא מוגדר ל-
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 והחביון לא יפגעו בביצועים של האפליקציה, צריך להשתמש בגודל קלט/פלט מינימלי של 256 KB ומעלה.
כדאי להשתמש בגדלים גדולים של פס לשימוש באפליקציות של מערכת קבצים מבוזרת. עומס עבודה של קלט/פלט אקראי עם גדלי פס גדולים (4MB ומעלה) משיג ביצועים מצוינים בדיסק מתמיד סטנדרטי, כי עומס העבודה דומה מאוד לגישה לדיסק של כמה זרמים רציפים.
מוודאים שהאפליקציה מייצרת מספיק פעולות קלט/פלט
צריך לוודא שהאפליקציה יוצרת מספיק פעולות קלט/פלט כדי להשתמש באופן מלא במגבלות של IOPS ושל קצב העברת הנתונים של הדיסק. כדי להבין טוב יותר את דפוס הקלט/פלט של עומס העבודה, כדאי לבדוק את השימוש בדיסק ואת מדדי הביצועים ב-Cloud Monitoring.
מוודאים שיש מספיק מעבד זמין במופע שמייצר את פעולות הקלט/פלט
אם למכונה הווירטואלית אין מספיק משאבי CPU, האפליקציה לא תוכל לנהל את פעולות הקלט/פלט בשנייה שצוינו קודם. מומלץ להקצות מעבד אחד לכל 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
כונני Persistent Disk תומכים בפעולות השמדה או בפקודות TRIM, שמאפשרות למערכות הפעלה להודיע לכוננים כשבלוקים כבר לא בשימוש. תמיכה בהסרה מאפשרת למערכת ההפעלה לסמן בלוקים בדיסק כבלוקים שכבר לא נדרשים, בלי לשלם את העלות של איפוס הבלוקים.
ברוב מערכות ההפעלה של Linux, מפעילים פעולות של ביטול שינויים כשמפעילים Persistent Disk במכונה הווירטואלית. מכונות וירטואליות של Windows Server 2012 R2 מאפשרות פעולות של ביטול שינויים כברירת מחדל כשמפעילים Persistent Disk.
הפעלת פעולות השמטה יכולה לשפר את הביצועים הכלליים של זמן הריצה, ויכולה גם להאיץ את הביצועים של הדיסק כשהוא מותקן בפעם הראשונה. פרמוט של נפח דיסק שלם יכול להיות תהליך ארוך, ולכן פרמוט עצלן הוא שיטה נפוצה. החיסרון בפורמט העצלני הוא שהעלות משולמת לרוב בפעם הראשונה שמתבצעת טעינה של אמצעי האחסון. אם משביתים את האתחול העצלן ומפעילים את פעולות ההסרה, אפשר לבצע פעולות מהירות של עיצוב והרכבה.
כדי להשבית את האתחול העצלן ולהפעיל את פעולות ההסרה כשמפרמטים דיסק, מעבירים את הפרמטרים הבאים אל 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 פועל היטב כשהפעולות discard מופעלות. עם זאת, אפשר להפעיל את fstrim מעת לעת בנוסף לפעולות ההסרה או במקום להשתמש בהן. אם אתם לא משתמשים בפעולות ביטול, אתם צריכים להריץ את הפקודה fstrim לפני שאתם יוצרים snapshot של דיסק האתחול. חיתוך של מערכת הקבצים מאפשר ליצור תמונות מצב קטנות יותר, וכך להקטין את העלות של אחסון תמונות מצב.
שינוי הערך של קריאה מראש
כדי לשפר את ביצועי הקלט/פלט, מערכות הפעלה משתמשות בטכניקות כמו readahead, שבה קוראים לזיכרון חלק גדול יותר מקובץ ממה שהתבקש, מתוך הנחה שקריאות עוקבות כנראה יזדקקו לנתונים האלה. הגדלה של קריאה מראש משפרת את קצב העברת הנתונים, אבל על חשבון הזיכרון וה-IOPS. הפחתה של קריאה מראש מגדילה את מספר פעולות הקלט/פלט בשנייה, אבל על חשבון התפוקה.
במערכות Linux, אפשר לקבל ולהגדיר את ערך הקריאה מראש באמצעות הפקודה blockdev:
$ sudo blockdev --getra /dev/DEVICE_ID
$ sudo blockdev --setra VALUE /dev/DEVICE_ID
ערך הקריאה מראש הוא <desired_readahead_bytes> / 512 בייטים.
לדוגמה, אם מדובר ב-readahead של 8 MB, 8 MB הם 8,388,608 בייטים (8 * 1,024 * 1,024).
8388608 bytes / 512 bytes = 16384
הגדרתם את blockdev ל-16384:
$ sudo blockdev --setra 16384 /dev/DEVICE_ID
שינוי של מכונה וירטואלית (VM) או יצירה של מכונה וירטואלית חדשה
יש מגבלות שקשורות לכל סוג מכונה וירטואלית, שיכולות להשפיע על הביצועים שאפשר לקבל מהדיסקים המצורפים. המגבלות האלה כוללות:
- הביצועים של Persistent Disk משתפרים ככל שמספר יחידות ה-vCPU הזמינות גדל.
- לא כל סוגי המכונות תומכים ב-Hyperdisk.
- שיעורי התעבורה היוצאת מהרשת עולים ככל שמספר ליבות ה-vCPU הזמינות עולה.
מוודאים שיש מעבדים פנויים
קריאה וכתיבה של נפחי דיסק לאחסון מתמיד דורשות מחזורי CPU ממכונת ה-VM. כדי להשיג רמות גבוהות מאוד ועקביות של IOPS, צריך שמעבדי ה-CPU יהיו פנויים לעיבוד קלט/פלט.
כדי להגדיל את מספר יחידות ה-vCPU שזמינות למכונה הווירטואלית, אפשר ליצור מכונה וירטואלית חדשה או לערוך את סוג המכונה של מכונה וירטואלית.
כדאי להשתמש ב-Google Cloud Hyperdisk
כדי לקבל יותר פעולות קלט/פלט בשנייה (IOPS) וקצב העברת נתונים (throughput), כדאי להשתמש בכרכים של Hyperdisk במקום בדיסקים לאחסון מתמיד, אם סדרת המכונות שלכם תומכת ב-Hyperdisk.
כדי לברר אם סדרת המכונות שלכם תומכת ב-Hyperdisk, אפשר לעיין במאמר תמיכה בסדרות מכונות ב-Hyperdisk.
אם סדרת המכונות של המופע תומכת ב-Hyperdisk, פועלים לפי השלבים הבאים כדי להשתמש באמצעי אחסון מסוג Hyperdisk:
בוחרים סוג Hyperdisk שמתאים לצרכים של עומס העבודה.
כדי לעבור לסוג Hyperdisk שבחרתם, אפשר לעיין בהוראות שבמאמר בנושא שינוי סוג הדיסק.
שינוי סדרת המכונות של המופע כדי לשפר את הביצועים
סדרות חדשות של מכונות וירטואליות בדרך כלל פועלות על מעבדים חדשים יותר, שיכולים להציע ביצועים טובים יותר מהדגמים הקודמים. בנוסף, מעבדים חדשים יותר יכולים לתמוך בפונקציונליות נוספת כדי לשפר את הביצועים של עומסי העבודה, כמו Advanced Matrix Extensions (AMX) או Intel Advanced Vector Extensions (AVX-512).
המאמרים הבאים
- כדי לעקוב אחרי הביצועים של הדיסק, בודקים את מדדי הביצועים של הדיסק ועוקבים אחרי תקינות הדיסק.
- השוואת ביצועים של נפחי אחסון מתמיד (persistent disk) שמצורפים למכונות וירטואליות של Linux.
- למחירון של Persistent Disk
- כאן מוסבר איך בודקים את מדדי הביצועים של הדיסק כדי לעקוב אחרי הביצועים שלו.