אחרי שמקצים נפחי אחסון של Google Cloud Hyperdisk, יכול להיות שיהיה צורך לבצע אופטימיזציה של הביצועים באפליקציה ובמערכת ההפעלה כדי לעמוד בדרישות הביצועים.
בקטעים הבאים נתאר כמה רכיבים מרכזיים שאפשר לשנות כדי לשפר את הביצועים, ונסביר איך אפשר להחיל חלק מהרכיבים האלה על סוגים ספציפיים של עומסי עבודה.
לסקירה כללית על הביצועים של Google Cloud Hyperdisk, אפשר לעיין במאמר מידע על הביצועים של Hyperdisk.
שימוש בעומק תור גבוה של קלט/פלט
זמן האחזור של נפחי Hyperdisk גבוה יותר מזה של דיסקים שמצורפים באופן מקומי, כמו SSD מקומי, כי הם מכשירים שמצורפים לרשת. הם יכולים לספק IOPS וקצב העברה גבוהים מאוד, אבל צריך לוודא שמבצעים מספיק בקשות קלט/פלט במקביל. מספר בקשות הקלט/פלט שמתבצעות במקביל נקרא עומק תור הקלט/פלט.
בטבלאות הבאות מפורטת עומק התור המומלץ של קלט/פלט כדי להבטיח שתוכלו להשיג רמת ביצועים מסוימת. הטבלאות מציגות הערכה גבוהה במקצת של ההשהיה האופיינית, כדי להציג המלצות שמרניות. בדוגמה הזו ההנחה היא שגודל הקלט/פלט הוא 16KB.
| Desired IOPS | עומק התור |
|---|---|
| 500 | 1 |
| 1,000 | 2 |
| 2,000 | 4 |
| 4,000 | 8 |
| 8,000 | 16 |
| 16,000 | 32 |
| 32,000 | 64 |
| 64,000 | 128 |
| 100,000 | 200 |
| 200,000 | 400 |
| 320,000 | 640 |
| התפוקה הרצויה (MB לשנייה) | עומק התור |
|---|---|
| 8 | 1 |
| 16 | 2 |
| 32 | 4 |
| 64 | 8 |
| 128 | 16 |
| 256 | 32 |
| 512 | 64 |
| 1,000 | 128 |
| 1,200 | 153 |
מוודאים שיש מעבדים פנויים
קריאה וכתיבה של נפחי Hyperdisk דורשות מחזורי CPU מהמכונה הווירטואלית. אם למכונה הווירטואלית אין מספיק משאבי CPU, האפליקציה לא תוכל לנהל את פעולות הקלט/פלט בשנייה שצוינו קודם. כדי להשיג רמות גבוהות ועקביות מאוד של IOPS, צריך לוודא שיש מעבדים פנויים לעיבוד קלט/פלט.
השבתה של הגנה מפני כתיבה קרועה ברמת מסד הנתונים כדי לבצע אופטימיזציה של פעולות כתיבה
מכיוון ש-Google Cloud Hyperdisk מספק הגנה מובנית מפני כתיבה קרועה, אתם יכולים להשבית את תכונות ההגנה ברמת מסד הנתונים כדי לצמצם את התקורה של קלט/פלט ולהגדיל את קצב העברת הנתונים של כתיבה למסד הנתונים בעד 25%. מידע נוסף על התכונה הזו זמין במאמר הגנה מפני כתיבה חלקית בדף הסקירה הכללית של Hyperdisk.
דרישות להגדרת הסביבה
כדי שההגנה מפני כתיבה קטועה של Hyperdisk תהיה יעילה, פעולות הכתיבה במסד הנתונים לא צריכות להתפצל לפני שהן מגיעות לשכבת האחסון. בהתאם למסד הנתונים, אפשר להשיג את זה באמצעות אחת מאפשרויות ההגדרה הבאות:
אפשרות 1: יישור השכבות לגבולות של בלוקים בגודל 16 KiB (מומלץ ל-MySQL ול-PostgreSQL)
מגדירים את מערכת ההפעלה, את מערכת הקבצים ואת שכבות התוכנה הביניים כדי לשמור על הגבול של 16 KiB. אם בוחרים באפשרות הזו, צריך לשמור על ההגדרה הספציפית הזו:
מערכת קבצים: שימוש במערכת קבצים מסוג
ext4. צריך ליצור את מערכת הקבצים עם האפשרותbigallocולהגדיר את גודל האשכול של מערכת הקבצים ל-16 KiB (16,384 בייט) או לכפולה גדולה יותר של 16 KiB שהיא חזקה של 2:mkfs.ext4 -O bigalloc -C 16384 /dev/<var>DEVICE_NAME</var>מחליפים את
DEVICE_NAMEבשם של מכשיר האחסון.הגדרות שלא נתמכות: כדאי להימנע מהגדרות שעלולות לגרום לכתיבות חלקיות מעל שכבת אחסון הבלוקים (block storage), כמו ההגדרות הבאות:
- הפעלת מסדי נתונים בקונטיינרים ב-Google Kubernetes Engine או ב-Kubernetes באירוח עצמי.
- אחסון קבצים של מסד נתונים במערכת קבצים
xfs, שבדרך כלל לא תומכת בגדלים מספיקים של בלוקים ברוב הפצות ה-Linux. - שימוש בתצורות של מערכי דיסקים עצמאיים מיותרים (RAID) או במנהלי נפחים לוגיים (LVM) שמבצעים striping של קלט/פלט.
- שימוש ב-Hyperdisk עם מטמון SSD מקומי, כולל
lvmcache,dm-cacheאוbcache. - שימוש בווירטואליזציה מקוננת למכונה הווירטואלית של מסד הנתונים.
אפשרות 2: שימוש ב-I/O אטומי של בלוקים ב-Linux (מומלץ ל-MariaDB)
אם מסד הנתונים או האפליקציה שלכם תומכים ב-I/O אטומי של בלוקים ב-Linux וניגשים לקבצים באמצעות I/O ישיר (O_DIRECT), אתם יכולים לעקוף את כללי ההגדרה שמפורטים באפשרות 1, בתנאי שאתם עומדים בתנאים הבאים:
- הדגל RWF_ATOMIC: האפליקציה צריכה להשתמש בקריאת המערכת
pwritev2()עם הדגלRWF_ATOMIC. כשמשתמשים בדגל הזה, ליבת Linux מוודאת שפעולת כתיבה מעובדת כבלוק רציף יחיד על ידי מכשיר Hyperdisk הבסיסי. אם ליבת המערכת לא יכולה להבטיח אטומיות, קריאת הכתיבה נכשלת באופן מיידי כדי למנוע השחתת נתונים. - מערכת הפעלה: גרסת הליבה של Linux צריכה להיות 6.11 ומעלה.
- מערכת קבצים: צריכה להיות
ext4אוxfsבגרסה 6.13 של ליבת Linux ואילך. - גישה לקבצים: האפליקציה צריכה לפתוח קבצים של מסד נתונים באמצעות קלט/פלט ישיר (
O_DIRECT). - מסדי נתונים נתמכים: אנחנו ממליצים על האפשרות הזו רק ל-MariaDB גרסה 11.x ואילך (לתמיכה כללית ב-Linux RWF_ATOMIC). MySQL ו-PostgreSQL לא תומכות בתכונה הזו.
הוראות מפורטות לאופטימיזציה של מסד נתונים ספציפי מופיעות במאמר בנושא הגדרת MySQL ב-Compute Engine.
בדיקת מדדי הביצועים של Hyperdisk
אפשר לבדוק את מדדי הביצועים של הדיסק ב-Cloud Monitoring, פתרון המעקב המשולב שלCloud de Confiance. אפשר להשתמש במדדים האלה כדי לבחון את הביצועים של הדיסקים ושל משאבים אחרים של מכונות וירטואליות בעומסי עבודה שונים של אפליקציות.
מידע נוסף זמין במאמר בנושא בדיקת מדדי הביצועים של הדיסק.
אפשר גם להשתמש בדף Observability במסוף כדי לראות את מדדי הביצועים של הדיסק.