דיסקים מתמידים מספקים את הביצועים שמתוארים בתרשים סוגי הדיסקים אם השימוש בכוננים של מכונת Compute Engine מספיק כדי להגיע למגבלות הביצועים. אחרי שקובעים את הגודל של נפחי ה-Persistent Disk בהתאם לצרכים שלכם מבחינת ביצועים, יכול להיות שיהיה צורך לבצע התאמות בעומס העבודה ובמערכת ההפעלה.
בקטעים הבאים מתוארים מאפיינים של מכונות וירטואליות ועומסי עבודה שמשפיעים על ביצועי הדיסק, ומוסברים כמה אלמנטים מרכזיים שאפשר לשנות כדי לשפר את הביצועים. חלק מההצעות ואיך ליישם חלק מהן על סוגים ספציפיים של עומסי עבודה.
גורמים שמשפיעים על ביצועי הדיסק
בקטעים הבאים מתוארים גורמים שמשפיעים על הביצועים של דיסק במכונת חישוב.
- מגבלות על תפוקת הכתיבה של תעבורת נתונים יוצאת (egress) ברשת
- קריאה וכתיבה בו-זמנית
- גודל נפח לוגי
- כמה דיסקים שמצורפים למופע חישוב יחיד
מגבלות על תעבורת נתונים יוצאת (egress) ברשת בנפח הכתיבה
למופע של Compute יש מגבלה על תעבורת נתונים יוצאת מהרשת שתלויה בסוג המכונה של המופע.
Compute Engine מאחסן נתונים בדיסק אחסון מתמיד עם כמה פעולות כתיבה מקבילות כדי להבטיח יתירות מובנית. בנוסף, לכל בקשת כתיבה יש תקורה שצורכת רוחב פס נוסף לכתיבה.
תנועת הכתיבה המקסימלית שיכולה לצאת ממופע של מחשוב היא מכסת היציאה מהרשת חלקי מכפיל רוחב הפס שכולל את השכפול והתקורה.
הגבלות על תעבורת נתונים יוצאת מהרשת מפורטות בעמודה Default egress bandwidth (Gbps) (רוחב פס ברירת מחדל של תעבורת נתונים יוצאת מהרשת (Gbps)) בטבלאות של סוגי המכונות עבור משפחות המכונות general purpose (למטרות כלליות), compute-optimized (מותאמות לצריכת מעבד גבוהה), storage-optimized (מותאמות לאחסון), memory-optimized (מותאמות לזיכרון) ו-accelerator-optimized (מותאמות למאיצים).
מכפיל רוחב הפס הוא בערך פי 1.16 בניצול מלא של הרשת, כלומר 16% מהבייטים שנכתבים הם תקורה. במקרה של אחסון מתמיד אזורי, מכפיל רוחב הפס הוא בערך פי 2.32, כדי לפצות על תקורה נוספת של שכפול.
במצב שבו פעולות קריאה וכתיבה של Persistent Disk מתחרות עם רוחב הפס של תעבורת נתונים יוצאת (egress) של הרשת, 60% מרוחב הפס המקסימלי של תעבורת נתונים יוצאת (egress) של הרשת, שמוגדר לפי סוג המכונה, מוקצים לכתיבה של Persistent Disk. 40% הנותרים זמינים לכל שאר תעבורת הנתונים היוצאת מהרשת. פרטים על תנועת יציאה אחרת מהרשת זמינים במאמר בנושא רוחב פס של תעבורת נתונים יוצאת.
בדוגמה הבאה אפשר לראות איך לחשב את רוחב הפס המקסימלי לכתיבה בדיסק מתמשך במכונת Compute 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 עם 1 vCPU
מגבלת תעבורת הנתונים היוצאת (egress) מהרשת היא:
2 Gbps / 8 bits = 0.25 GB per second = 250 MB per second
הקצאת רוחב הפס של האחסון המתמיד (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, מאפשרים לבצע פחות פעולות קריאה.
אי אפשר להגיע בו-זמנית למגבלות של נפחי אחסון מסוג Persistent Disk מבחינת קצב העברת נתונים ופעולות קלט/פלט בשני הכיוונים – קריאה וכתיבה.
החישוב של קצב העברת הנתונים הוא IOPS * I/O size. כדי לנצל את מגבלות התפוקה המקסימליות לקריאה וכתיבה בו-זמניות ב-SSD Persistent Disk, צריך להשתמש בגודל קלט/פלט כך שסך ה-IOPS של הקריאה והכתיבה לא יעלה על מגבלת ה-IOPS.
בטבלה הבאה מפורטות מגבלות ה-IOPS לכל מכונת חישוב לקריאות וכתיבות בו-זמניות.
| Standard Persistent Disk | דיסק מתמיד שמבוסס על SSD (8 vCPUs) | דיסק מתמיד שמבוסס על 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 לשנייה) לכל אינסטנס לקריאות וכתיבות בו-זמניות.
| Standard Persistent Disk | SSD Persistent Disk (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 באמצעות ניהול נפחים לוגיים בתוך מכונת החישוב. גודל נפח גדול יותר משפיע על הביצועים בדרכים הבאות:
- לא כל מערכות הקבצים המקומיות פועלות טוב בקנה מידה כזה. יכול להיות שפעולות נפוצות, כמו טעינה ובדיקה של מערכת הקבצים, יימשכו יותר זמן מהצפוי.
- הביצועים המקסימליים של דיסק מתמשך מושגים בגדלים קטנים יותר. הקריאה או הכתיבה בדיסקים עם נפח אחסון כזה במופע מחשוב אחד נמשכות זמן רב יותר. אם האפליקציה שלכם תומכת בכך, כדאי להשתמש בכמה מכונות וירטואליות כדי להגדיל את התפוקה הכוללת של המערכת.
- יצירת תמונת מצב של מספרים גדולים של Persistent Disk עשויה להימשך זמן רב יותר מהצפוי, ועשויה לספק תצוגה לא עקבית של הנפח הלוגי שלכם ללא תיאום מדוקדק עם האפליקציה.
כמה דיסקים שמצורפים למופע חישוב יחיד
מגבלות הביצועים של דיסקים כשמחוברים כמה דיסקים למופע חישוב תלויות בסוג הדיסקים – אם הם מאותו סוג או מסוגים שונים.
כמה דיסקים מאותו סוג
אם יש לכם כמה דיסקים מאותו סוג שמצורפים למופע של מכונת חישוב באותו מצב (לדוגמה, קריאה/כתיבה), מגבלות הביצועים זהות למגבלות של דיסק יחיד עם גודל משולב של הדיסקים האלה. אם משתמשים בכל הדיסקים ב-100%, מגבלת הביצועים הכוללת מתחלקת באופן שווה בין הדיסקים, בלי קשר לגודל היחסי של הדיסק.
לדוגמה, נניח שיש לכם דיסק pd-standard בנפח 200GB ודיסק pd-standard בנפח 1,000GB. אם לא משתמשים בדיסק בנפח 1,000GB, הדיסק בנפח 200GB יכול להגיע למגבלת הביצועים של דיסק סטנדרטי בנפח 1,200GB. אם משתמשים בשני הדיסקים ב-100%, לכל אחד מהם יש מגבלת ביצועים של דיסק בנפח 600GB (1,200GB / 2 דיסקים = דיסק בנפח 600GB).pd-standard
כמה דיסקים מסוגים שונים
אם מצרפים סוגים שונים של דיסקים למופע Compute, הביצועים המקסימליים האפשריים הם מגבלת הביצועים של הדיסק המהיר ביותר שהמופע Compute תומך בו. הביצועים המצטברים של הדיסקים המצורפים לא יעלו על מגבלות הביצועים של הדיסק המהיר ביותר שמופע המחשוב תומך בו.
אופטימיזציה של הדיסקים לעומסי עבודה שמתמקדים ב-IOPS או בתפוקה
ההמלצות לשיפור הביצועים תלויות בבחירה שלכם בין מיקסום של פעולות קלט/פלט בשנייה (IOPS) לבין מיקסום של קצב העברת הנתונים (throughput).
עומסי עבודה שמתמקדים ב-IOPS
במסדי נתונים, בין אם הם מסוג SQL או NoSQL, יש דפוסי שימוש של גישה אקראית לנתונים. Google ממליצה על הערכים הבאים לעומסי עבודה שמתמקדים ב-IOPS:
ערכי עומק של תור קלט/פלט של 1 לכל 400 עד 800 של IOPS, עד למגבלה של 64 בכרכים גדולים
מעבד אחד בחינם לכל 2,000 פעולות קלט/פלט של קריאה אקראית, ומעבד אחד בחינם לכל 2,500 פעולות קלט/פלט של כתיבה אקראית
אם סוג המכונה של מופע Compute תומך בהם, אפשר להשתמש בדיסקים מסוג 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. מתזמן קלט/פלט (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.
מוודאים שיש מספיק מעבד זמין במופע שמייצר את פעולות הקלט/פלט
אם יש מחסור במעבד במכונת החישוב, האפליקציה לא תוכל לנהל את פעולות הקלט/פלט שמתוארות למעלה. מומלץ להקצות מעבד אחד לכל 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 Disks תומכים בפעולות השמדה או בפקודות 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.
שינוי מכונת מחשוב או יצירת מכונה חדשה
יש מגבלות שמשויכות לכל סוג מכונה שיכולות להשפיע על הביצועים שאפשר לקבל מהדיסקים המצורפים. המגבלות האלה כוללות:
- הביצועים של Persistent Disk משתפרים ככל שמספר ה-vCPU הזמינים גדל.
- לא כל סוגי המכונות תומכים ב-Hyperdisk.
- שיעורי היציאה מהרשת עולים ככל שמספר ה-vCPU הזמינים עולה.
מוודאים שיש מעבדים פנויים
כדי לקרוא ולכתוב בכרכים של Persistent Disk, נדרשים מחזורי CPU ממופע המחשוב. כדי להשיג רמות גבוהות מאוד ועקביות של IOPS, צריך שמעבדי ה-CPU יהיו פנויים לעיבוד קלט/פלט.
כדי להגדיל את מספר יחידות ה-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
- איך בודקים את מדדי הביצועים של הדיסק