אחרי הקצאת נפחי Google Cloud Hyperdisk, יכול להיות שתצטרכו לבצע כוונון ביצועים באפליקציה ובמערכת ההפעלה כדי לעמוד בדרישות הביצועים שלכם.
בקטעים הבאים נתאר כמה רכיבים מרכזיים שאפשר לכוונן כדי לשפר את הביצועים, ואיך אפשר להחיל חלק מהרכיבים האלה על סוגים ספציפיים של עומסי עבודה.
במאמר מידע על הביצועים של Hyperdisk מוסבר איך פועלים הביצועים של Google Cloud Hyperdisk.
שימוש בעומק תור קלט/פלט גבוה
זמן האחזור של אמצעי אחסון ב-Hyperdisk גבוה יותר מזה של דיסקים שמחוברים באופן מקומי, כמו כונני SSD מקומיים, כי הם מכשירים שמחוברים לרשת. הם יכולים לספק קצב העברת נתונים ו-IOPS גבוהים מאוד, אבל צריך לוודא שמספיק בקשות קלט/פלט (I/O) מתבצעות במקביל. מספר בקשות הקלט/פלט שמבוצעות במקביל נקרא עומק התור של הקלט/פלט.
בטבלאות הבאות מוצג עומק התור המומלץ של פעולות קלט/פלט כדי להבטיח שתוכלו להגיע לרמת ביצועים מסוימת. הטבלאות מבוססות על הערכת יתר קלה של זמן האחזור האופייני, כדי להציג המלצות שמרניות. בדוגמה הזו אנחנו מניחים שאתם משתמשים בגודל קלט/פלט של 16KB.
| מספר ה-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) מהמכונה הווירטואלית. אם למכונה הווירטואלית אין מספיק משאבי מעבד, האפליקציה לא תוכל לנהל את פעולות הקלט/פלט לשנייה שתוארו קודם. כדי להגיע לרמות גבוהות ועקביות של IOPS, צריך מעבדים פנויים לעיבוד קלט/פלט.
השבתת ההגנה מכתיבה ברמת מסד הנתונים כדי לשפר את הכתיבה
מכיוון ש-Google Cloud Hyperdisk מספק הגנה מובנית מפני כתיבה קרועה, אתם יכולים להשבית את תכונות ההגנה ברמת מסד הנתונים כדי להפחית את התקורה של הקלט/פלט ולהגדיל את קצב העברת הנתונים של הכתיבה במסד הנתונים בשיעור של עד 25%. מידע נוסף על התכונה הזו זמין בקטע הגנה מכתיבה קטועה בדף הסקירה הכללית של Hyperdisk.
דרישות להגדרת הסביבה
כדי שההגנה מכתיבה קטועה של Hyperdisk תהיה יעילה, אסור שהכתיבה במסד הנתונים תעבור פרגמנטציה לפני שהיא מגיעה לשכבת האחסון. בהתאם למסד הנתונים, אפשר לעשות זאת באמצעות אחת מאפשרויות ההגדרה הבאות:
אפשרות 1: התאמת השכבות לגבולות של בלוקים בגודל 16KiB (מומלץ ל-MySQL ול-PostgreSQL)
מגדירים את מערכת ההפעלה, את מערכת הקבצים ואת שכבות התוכנה שביניהן כך שישמרו על הגבול של 16KiB. אם אתם משתמשים באפשרות הזו, אתם צריכים לשמור על ההגדרה הספציפית הזו:
מערכת קבצים: משתמשים במערכת קבצים של
ext4. צריך ליצור את מערכת הקבצים עם האפשרותbigallocולהגדיר את גודל האשכול של מערכת הקבצים ל-16 KiB (16,384 בייטים) או לכפולה גדולה יותר של חזקה של שתיים של 16 KiB:mkfs.ext4 -O bigalloc -C 16384 /dev/<var>DEVICE_NAME</var>מחליפים את
DEVICE_NAMEבשם של התקן האחסון.הגדרות לא נתמכות: הימנעו מהגדרות שיכולות לגרום לכתיבה קרועה מעל שכבת אחסון הבלוקים, כמו:
- הפעלת מסדי נתונים בקונטיינרים ב-Google Kubernetes Engine או ב-Kubernetes באירוח עצמי.
- אחסון קובצי מסד נתונים במערכת קבצים מסוג
xfs, שבדרך כלל לא תומכת בגודלי בלוקים מספיקים ברוב הפצות Linux. - שימוש בהגדרות של מערך משוכפל של דיסקים עצמאיים (RAID) או במנהלי נפחים לוגיים (LVM) שמפצלים את הקלט/פלט.
- שימוש ב-Hyperdisk עם מטמונים של כונני SSD מקומיים, כולל
lvmcache,dm-cacheאוbcache. - שימוש בווירטואליזציה בתצורה מקוננת למכונה הווירטואלית של מסד הנתונים.
אפשרות 2: שימוש ב-block atomic I/O של Linux (מומלץ ל-MariaDB)
אם מסד הנתונים או האפליקציה תומכים ב-Linux block atomic I/O וניגשים לקבצים באמצעות קלט/פלט ישיר (O_DIRECT), אתם יכולים לעקוף את כללי ההגדרה שמפורטים באפשרות 1, בתנאי שאתם עומדים בתנאים הבאים:
- הדגל RWF_ATOMIC: האפליקציה צריכה להשתמש בקריאת המערכת
pwritev2()עם הדגלRWF_ATOMIC. כשמשתמשים בדגל הזה, הליבה של Linux מוודאת שפעולת הכתיבה מעובדת כבלוק רציף אחד על ידי מכשיר Hyperdisk הבסיסי. אם הליבה לא יכולה להבטיח אטומיות, קריאת הכתיבה נכשלת מיד כדי למנוע פגיעה בנתונים. - מערכת הפעלה: ליבת Linux בגרסה 6.11 ואילך.
- מערכת קבצים: חייבת להיות
ext4אוxfsבגרסת ליבה של Linux מגרסה 6.13 ואילך. - גישה לקבצים: האפליקציה צריכה לפתוח קובצי מסד נתונים באמצעות קלט/פלט ישיר (
O_DIRECT). - מסדי נתונים נתמכים: אנחנו ממליצים על האפשרות הזו רק ל-MariaDB בגרסה 11.x ואילך (לתמיכה כללית ב-Linux RWF_ATOMIC). MySQL ו-PostgreSQL לא תומכים בתכונה הזו.
הוראות מפורטות לאופטימיזציה של מסד נתונים ספציפי זמינות במאמר הגדרת MySQL ב-Compute Engine.
בדיקת מדדי הביצועים של Hyperdisk
אתם יכולים לבדוק את מדדי הביצועים של הדיסק ב-Cloud Monitoring, פתרון המעקב המשולב שלCloud de Confiance. אתם יכולים להשתמש במדדים האלה כדי לבחון את הביצועים של הדיסקים ושל משאבים אחרים של המכונה הווירטואלית בעומסי עבודה שונים של אפליקציות.
מידע נוסף זמין במאמר בדיקת מדדי הביצועים של הדיסק.
אפשר גם להשתמש בדף Observability במסוף כדי לראות את מדדי הביצועים של הדיסק.